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ABSTRACT 

This  thesis  gives  a  short,  concise  description  of  the  U.S. 
Navy  SNAP-II  (Shipboard  Non-Tactical  Automated  Data  Processing 
Program)  computer  system,  and  through  a  post  implementation 
review  of  six  ships  having  the  system  installed,  delineates 
concerns  and  problem  areas  with  the  SNAP-II  system  as  perceived 
by  the  end-users.  Major  areas  of  concern  that  emerged  were 
training,  documentation,  and  the  role  of  management  in  relation 
to  the  SNAP-II  system,  both  internal  and  external  to  a  U.S. 

Navy  ship.  An  analysis  of  these  issues  is  conducted  and  is 
the  basis  for  recommendations  on  how  to  improve  the  SNAP-II 
program. 
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I.  INTRODUCTION 


The  SNAP- II  (Shipboard  Non- tact ical  Automatic  Data 
Processing  Program)  program  was  initiated  in  response  to  a 
Chief  of  Naval  Operations  (CNO)  objective  to  reduce  the 
administrative  burden  on  shipboard  personnel,  which  would 
have  a  resultant  improvement  in  fleet  readiness  and  a 
positive  effect  on  the  morale  and  retention  of  personnel. 

As  conceptualized,  the  system  would  provide  automatic 
data  processing  equipment  to  small  surface  ships  and  submarines 
reducing  the  manual  burden  on  personnel  in  the  administration 
of  maintenance,  supply,  and  pay  and  personnel  matters.  The 
system  was  designed  for  a  life  cycle  of  twenty  years,  with  a 
key  proviso  in  its  charter  being  that  additional  personnel 
would  not  be  required  to  operate  or  maintain  the  equipment. 

The  program  has  been  referred  to  by  various  agencies  as 
a  "Real-time  MIS"  (Ref.  l:p.  1],  a  system  to  "provide 
automated  support  for  maintenance,  supply,  and  pay  and 
personnel  functions”  [Ref.  2:Encl.  (5),  p.  5],  and  "Automated 
Information  System"  [Ref.  l:p.  1]  and  [Ref.  5:p.  1],  all  of 
which  have  different  connotations  of  expected  use. 

The  current  program  calls  for  the  installation  of  a  total 
of  4  59  SNAP- I  I  systems- -17  at  shore  sites  for  training  and 
support,  and  442  on  afloat  units.  As  of  51  January  198b,  105 
systems  have  been  installed  afloat  (55  Pacific  fleet,  50 


Atlantic  fleet)  and  three  at  shore  locations.  No  submarines 
have  yet  had  the  system  installed,  although  the  first 
installation  has  been  scheduled  to  start  in  January  1986. 

With  almost  one-third  of  the  systems  installed  in  the 
fleet,  a  need  was  perceived  to  obtain  user  feedback  to 
ascertain  just  how  the  "fleet"  was  receiving  the  SNAP- II 
system  and  whether  they  were  satisfied  with  the  product. 
Subsidiary  questions  of  whether  the  system  was  being  utilized 
to  its  full  capability  by  fleet  units  and  adequately  supported 
by  the  shore  establishment  were  also  of  importance. 

The  purpose  of  this  thesis  is  to  investigate  end  user 
satisfaction  with  the  SNAP-II  program,  identify  concerns  and 
discuss  emergent  issues  that  may  be  of  significance.  This 
was  accomplished  through  a  post  - impl ementat ion  review  of  six 
ships,  three  of  the  Atlantic  Pleet  and  three  of  the  Pacific 
Fleet.  As  no  submarines  currently  have  the  system  installed, 
tb~y  were  excluded.  The  reviews  were  conducted  in  January 
1986,  using  both  open  and  closed  format  interview  techniques. 
Personnel  interviewed  ranged  from  the  Commanding  Officers  to 
senior  enlisted  personnel.  The  main  thrust  of  the  interviews 
was  on  a  perceptive  or  subjective  basis.  Quantitative 
information  was  neither  sought  nor  desired. 

Program  and  System  descriptions  are  included  in  Chapters 
II  and  III,  with  the  individual  ship  reviews  and  summaries 
contained  in  Chapters  IV  and  V.  Discussion  of  emergent 
issues  follows,  w'ith  conclusions  and  recommendations  appearing 
in  the  final  Chapter. 


II.  SNAP- 1 1  PROGRAM  ORGANIZATION 


Program  Organization  is  divided  into  two  areas--the 
internal  organization  of  the  ship  (afloat) ,  and  the  Navy  wide 
organization  (ashore)  that  manages  implementation,  any  changes 
to  program  direction,  and  provides  assistance  to  correct 
material  casualties  affecting  the  SNAP- 1 1  software  and 
hardware . 

A.  SHIP'S  INTERNAL  ORGANIZATION 

With  minor  variances,  the  internal  administrative 
organization  of  a  typical  Navy  ship  is  shown  in  Figure  (1). 
Variations  will  exist  between  types  of  ships.  A  department 
is  composed  of  several  divisions,  and  each  division  is 
composed  of  of  one  or  more  work  centers,  which  are  the  basic 
units  for  maintenance  administration  and  personnel 
assignments . 

A  department  is  headed  by  an  experienced  officer,  with 
the  divisions  headed  by  junior  officers.  The  work  centers 
are  headed  by  senior  enlisted  personnel. 

Superimposed  on  this  organization  is  the  SNAP- II 
Organization,  Figure  2,  which  utilized  the  same  personnel 
from  the  administrative  organization  in  a  secondary,  or 
collateral  duty  basis  to  administer,  operate  and  maintain  the 


svstem . 


The  guidelines  on  who  performs  what  SNAP- I I  tasks  are 
contained  in  formal  instructions  issued  by  the  Type  Commanders 
(The  role  of  the  Type  Commander  is  delineated  in  Figure  (5). 

Of  note  is  that  the  Type  Commander  has  issued  instructions 
concerning  only  the  management  of  the  SNAP- 1 1  system. 

Guidance  as  to  how  to  manage  with  the  system  has  not  been 
issued  at  any  level -- shipboard  managers  are  left  to  their 
own  initiative  as  to  how  to  integrate  the  system  within  their 
management  structure  and  style.  Specific  SNAP  jobs  and  their 
responsibilities  are  covered  in  Chapter  III. 

B.  SNAP- 1 1  PROGRAM  ORGANIZATION 

The  SNAP- II  program  organization  extends  from  the  Office 
of  the  Chief  of  Naval  Operations  down  to  the  individual  ship; 
its  purpose  is  threefold: 

-  install  and  implement  the  program 

-  repair  any  casual t  ies  to  hardware  or  software 

-  provide  guidance  and  policy  relevant  to  program  changes 
and  direction 

Figure  (4)  delineates  the  organizational  relationships,  but 
does  not  attempt  to  show  the  funding  flow  for  the  program. 
Several  terms  must  be  defined  to  understand  the  program: 

-  Program  Sponsor- - that  office  charged  with  overall  policy 
guidance  concerning  the  SNAP  program 

-  Program  Manager- -coordinates  all  aspects  of  the  SNAP- 1  I 

program  * 

-  Functional  Sponsor--for  each  of  the  functional  areas, 
certifies  individual  requirements  to  program  manager 
and  functional  manager 

-  Functional  Manager- -executes  the  guidance  of  the 
Functional  Sponsor  by  generating  requirement  specification 
for  software  that  must  be  developed. 


FLEET  COMMANDER  IN  CHIEF 


Figure  3 


(TYPE  =  SUBMARINE,  SURFACE 
AIR) 


(SUBMARINE  OR  CRUISER/ 
DESTROYER) 


(SEVERAL  SQUADRONS  TO  A 
CROUP) 


(MULTIPLE  SHIPS  TO  A 
SQUADRON) 


Fleet  Administrative  Organization 


Figure  4.  SNAP  II  Program  Management 
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To  execute  SNAP- 1 1  installation  and  implementation,  two 
agencies  are  directly  involved:  Naval  Sea  Systems  Command 
(NAVSEA)  and  Navy  Management  Systems  Support  Office  (NAVMASSO). 
(The  Type  Commander  is  involved  only  from  the  aspect  of 
scheduling).  NAVSEA,  through  NAVSEA  Support  Centers 
(NAVSEACEN ' s )  on  the  East  and  West  coasts,  supervises  the 
installation  of  system  hardware,  which  is  done  by  the  con¬ 
tractor,  Systems  Management  .American  (SMA)  Corporation. 

Software  installation  is  accomplished  by  NAVMASSO,  who  has 
also  assumed  the  responsibilities  for  coordinating  the 
initial  implementation  on  ships. 

Problems  that  develop  after  implementation  are  also 
handled  by  these  two  agencies- -hardware  problems  by  NAVSEA, 
software  problems  by  NAVMASSO.  Problems  can  be  reported 
through  the  formal  CASREP  method,  or  handled  by  initiating 
"Trouble  Reports"  to  NAVMASSO  for  software  problems,  or 
"Direct  Fleet  Support"  requests  to  the  Type  Commander  for 
hardware  problems,  who  will  then  coordinate  action  with 
NAVSEACEN's  [Ref.  4:p.  1]  and  [Ref.  5:p.  1]. 

User  feedback  for  improvements  or  additions  to  the  SNAP- 
II  system  is  handled  via  a  formal  mechanism  called  "change 
proposals".  They  are  forwarded  by  the  ship  to  the  Type 
Commander  [Ref.  4: Enel.  (5)]  and  [Ref.  5:Encl.  (2)],  who  in 
turn  will  assess  them  and  forward  them  to  the  Fleet  Commander- 
in-Chief  (The  Type  Commander  may  forward  the  change  proposal 
to  NAVMASSO  for  a  cost-benefit  analysis  if  that  has  not  been 


-- 
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done.)-  If  the  proposal  has  sufficient  merit,  it  will  be 
sent  to  the  Program  Coordinator  (OP-945),  who  will  pass  it 
to  the  appropriate  Functional  Sponsor.  The  Functional 
Sponsor  will  approve/disapprove  the  proposal,  and  task  the 
specific  Functional  Manager  to  develop  specifications  for  the 
change  if  the  request  is  approved. 

NAVMASSO  incorporates  the  changes  as  directed  by  the 
Functional  Managers,  and  the  change  is  distributed  to  the 
fleet  via  updates  to  existing  software  or  by  completely  new 
versions  of  the  software. 

Issues  of  sufficient  importance  that  cannot  be  resolved 
at  the  higher  levels  due  to  funding  constraints  or  policy 
implications  are  referred  to  the  Fleet  Non-tactical  ADP 
Policy  Council.  [Ref.  6:p.  4] 
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III.  SNAP- 1 1  SYSTEM  DESCRIPTION 


A  brief  description  of  the  SNAP- 1 1  system  elements  is 
necessary  to  understand  the  essence  of  the  system  and  the 
environment  within  which  the  system  operates.  These  elements 


-  Instal lat ion/ implementat ion 

-  Hardware 

-  Software 

-  Personnel 

-  Training 


A.  INSTALLATION/ IMPLEMENTATION 
1 .  Principal  Agencies 

There  are  three  principal  agencies  that  deal  with  an 
individual  ship  to  install  and  implement  the  SNAP-II  System: 

-  Type  Commander 

-  NAVSEA 

-  NAVMASSO 

The  Type  Commander  is  responsible  for  coordinating 
the  ship's  schedule  for  installation,  obtaining  training  for 
the  ship's  Hardware  Maintainers,  and  monitoring  the  progress 
of  installation.  [Ref.  7:p.  5] 

The  respective  NAVSEA  Support  Centers  (Atlantic  and 
Pacific)  supervise  the  contractor's  installation  of  hardware, 
coordinating  their  activities  with  NAVMASSO  and  participating 
in  hardware  certification  [Ref.  8:p.  10-1].  Although  not 
directly  involved  in  hardware  installation,  NAVMASSO 


coordinates  the  entire  evolution  and  monitors  progress 
through  a  "Milestone  Tracking  System"  [Ref.  9:p.  A -  2 ] . 


2 .  Software  and  Training 

Software  and  initial  user  training  are  the  responsibility 
of  NAVMASSO.  Once  the  hardware  is  installed  and  certified  as 
operational,  the  software  installation  and  the  loading  of  the 
data  bases  is  done  by  NAVMASSO. 

Once  software  has  been  installed,  NAVMASSO  conducts 
training  on  board  the  ship  for  a  period  of  two  weeks. 

3 .  Hardware 

The  hardware  installation  can  take  three  to  seven 
weeks,  depending  on  the  class  of  ship  (Table  I).  Table  II 
was  compiled  from  various  sources  previously  cited  and 
delineates  a  "typical"  installation  schedule  for  a  ship. 

Prior  to  commencing  the  installation,  site  surveys  and 
preparations  will  be  conducted  by  the  contractor  under  NAV  - 
SHAGEN  supervision.  The  contractor  is  responsible  for 
providing  all  equipment  and  material  incident  to  hardware 
installation  [Ref.  7:p.  5]. 

4 .  Data 

Software  installation  is  preceded  by  the  construction 
of  various  SNAP- I  I  data  bases.  The  ship  itself  is  the  source 
of  the  following  items  of  data  [Ref.  9 : pp .  11-17]: 

-  ship  organizational  information 

-  ship  personnel  data 

-  stock  record  card  (NAVSUP  1114)  data 

-  material  outstanding  requisition  file 

-  COSAL 

-  financial  data 


TABLE  I  I 


SHIPBOARD  IMPLEMENTATION  EVENTS 


ACTION  DATE 

EVENT 

RESPONSIBILITY 

D- 180 

IDENTIFY  SCHEDULE 

IDENTIFY  SHIP'S  CURRENT  ADP 
EQUIPMENT 

NAVMASSO/ TYCOM 
NAVMASSO 

D- 60  TO  90 

PRE- IMPLEMENTATION  BRIEF 

SITE  SURVEY 

STOCK  RECORD  CARD  SURVEY 

OBTAIN  TRAINING  QUOTAS 

DATA  COLLECTION  FORMS  TO  SHIP 

TYCOM 

NAVSEACEN 

TYCOM 

TYCOM/ NAVMASSO 
NAVMASSO 

D- 49/D- 2 1 

SITE  PREPARATION/ INSTALLATION 
(DEPENDING  ON  SHIP  CLASS) 

NAVSEA/ CONTRACTOR 

D-  50 

DELIVER  DATA  FORMS  TO 

NAVMASSO 

SHIP 

D-  25 

CSMP  CUTOFF 

SHIP/TYCOM 

D-  17 

STOCK  RECORD  BATTERY, 
OUTSTANDING  REQUISITION  FILES 
PICKUP  (FOR  CONVERSION) 

NAVMASSO/ SHI P 

D-  14 

STOCK  RECORD  BATTERY/FILES 
RETURNED  TO  SHIP 

NAVMASSO 

D-  1 

HARDWARE  SYSTEM  TEST,  NAVY 
ACCEPTANCE 

NAVSEA/CONTRACTOR 

D-0 

SOFTWARE/ DATA  BASE  LOAD 

NAVMASSO 

D+l 

USER  TRAINING  ON  BOARD 

NAVMASSO 

D+  50 


SUBMIT  ADPPRS  DATA  TO  TYCOM 
SUBMIT  OPNAV  4790/CK'S 


SHIP 


External  sources  that  provide  data  that  will  be  integrated 
into  the  ship's  data  bases  are  as  follows: 

-  SPCC//NAMMSO- -Weapon  Systems  File  (WSF) 

-  Type  Commander- -CSMP 

-  NMPC- -personnel  data 

-  NWS  Concord- -MEASURE  data 

The  collection  of  all  the  above  information  is  the 
responsibility  of  NAVMASSO,  who  will  convert  them  to  electronic 
media  or  supervise  a  contractor  who  will  perform  the  work. 

It  should  be  noted  that  any  activities  or  transactions  that 
affect  the  various  ship's  files/records  that  occur  during  the 
conversion  period  when  NAVMASSO  is  constructing  the  various 
data  bases  must  be  saved  by  the  ship  and  entered  in  the  SNAP- 
II  System  after  implementation.  The  specific  responsibilities 
are  outlined  in  the  SNAP- II  Implementation  Planning  Document, 
promulgated  by  NAVMASSO  [Ref.  9;pp.  7-11]. 

B.  HARDWARE 

1 .  Configuration 

The  description  of  the  hardware  is  divided  into  three 

areas : 

-  Central  Processing  Unit  (CPU)  and  Memory  Devices 

-  Peripheral  Input/Output  Devices 

-  Support  Equipment 

The  exact  configuration  for  each  ship  class  is  shown  in 
Table  III,  with  the  relationship  of  the  equipment  layout 
illustrated  in  Figure  (5)  [Ref.  8 : pp .  2/1-2/91. 

2 .  CPU 

The  Central  Processing  Unit  is  an  of f -  the- she  1 f 
commercial  product,  the  HARRIS  11500  m  in  i -computer .  It  is 
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Figure  3.  SNAP  II  User  Hardwar 


installed  in  a  rack  cabinet  that  also  includes  Hard  Disk 
Memory  Storage  Units,  perforated  paper  tape  and  magnetic  tape 
input/output  devices.  Another  input/output  device,  the  floppy 
disk  drive,  is  co-located  in  the  same  compartment  as  the  CPU 
and  rack  cabinet. 

3 .  Peripheral  Devices 

The  peripheral  input/output  devices  include  the  user 
terminals  ( KVDT- -  Keyboard  Video  Display  Terminals),  various 
types  of  printers,  and  a  paper  card  reader,  which  is  usually 
installed  in  the  Supply  Department. 

The  KVDT's  are  the  devices  through  which  the  users 
interact,  or  use,  the  SNAP-II  system.  It  is  a  Cathode  Ray 
Tube  (CRT)  with  a  keyboard  attached. 

There  are  three  kinds  of  printers  associated  with  the 
system.  A  line  printer  is  used  in  high  volume  printing  jobs 
using  16  inch  wide  computer  paper.  A  word  processing  printer 
produces  letter-quality  correspondence  on  standard  size  paper 
and  a  display  printer  provides  a  copy  of  what  the  user  is 
actually  seeing  on  his  KVDT  screen. 

4 .  Support  Equipment 

The  support  equipment  installed  will  be  discussed 
only  briefly,  as  the  user  is  not  directly  concerned  with  them. 
These  include  electrical  compensators  for  protecting  system 
components  from  electrical  outages  or  surges,  and  the  com¬ 
munications  subsystem,  which  allows  for  communication  from 
the  CPU  to  the  various  memory  devices  and  peripheral  equipment 
such  as  printers  and  KVDT's. 


C.  SOFTWARE 


The  SNAP- 1 1  system  was  designed  to  "reduce  the  burden  on 
shipboard  personnel  and  freeing  personnel  resources  for  use 
in  other  areas."  [Ref.  l:p.  1]  The  software,  written  in 
COBOL,  embodies  this  goal.  Software  is  the  collection  of 
programs  that  are  used  to  perform  tasks  (e.  g.,  controlling 
hardware,  maintaining  the  CSMP,  inventory  management). 

1 .  Software  Categories 

The  SNAP- 1 1  software  is  divided  into  two  general 
categories:  system  software  and  application  software, 

a.  System  Software 

System  software  consists  of  operating  system 
programs  and  utilities.  The  operating  system  controls  the 
hardware,  and  the  utility  programs  are  used  to  perform 
general  functions  in  support  of  all  software.  The  system 
software  is  provided  by  Harris  as  part  of  the  hardware 
package.  The  following  is  a  brief  description  of  the 


software  provided: 

(1)  Vulcan  Operating  System  (VOS).  An  operating 
system  is  a  group  of  programs  that  "govern  the  control  of 


equipment  resources  such  as  processors  (CPU),  main  storage 
memory,  secondary  memory  (disk,  tape),  Input/Output  devices, 
and  files."  [Ref.  9:p.  1]  In  simple  terms,  the  operating 
system  makes  the  hardware  work  together  to  achieve  the 
intended  results  of  the  application  software. 


(2)  Utilities.  The  following  utilities  are 


provided : 

-  MUSE- -a  word  processing  program 

-  BASIC--a  programming  language 

-  Sort/merge- -a  file  processing  program 

b.  Application  Software 

The  application  software  is  designed,  developed, 
and  maintained  by  NAVMASSO,  the  Central  Design  Activity  (CDA) . 
The  following  are  descriptions  of  the  subsystems  that  comprise 
the  application  software: 

(1)  System  Management  Subsystem  (SMS) .  The  SMS 
"performs  system  management  and  service  tasks  in  support  of 
the  other  functional  subsystems."  [Ref.  8:p.  2-19]  SMS 
controls  file  access,  provides  on-line  user  manuals,  controls 
report  queuing,  and  provides  user-to-user  message  processing. 
"The  SMS  also  ensures  the  protection  of  system  data  integrity 
by  providing  backup,  recovery,  and  transaction  logging 
functions."  [Ref.  8 : pp .  2-19]  Figure  (6)  depicts  the  SMS 
subsystem . 

(2)  Maintenance  Data  Subsystem  (SMS).  MDS  will 
consist  of  the  Organizational  Maintenance  Management  System 
(OMMS)  and  the  Planned  Maintenance  System  (PMS)  when 

r  e  1  e  a  s  c  d  . 

The  Organizational  Maintenance  Management  System  (OMMS) 
provides  organizational  maintenance  capability.  This 
system  includes  5-M  functions  related  to  the  Current 
Ship's  Maintenance  Project  Master  (CMPM)  data  base.  This 
data  base  consists  of  Maintenance  Data  System  (MDS) 
actions,  Configuration  Change  (CK)  actions,  Ship's  Force 
Work  List  (SFWL)  action,  TOCDOC  maintenance,  and  MEASURE. 
[Ref.  1 1 : p  .  5 | 


Figure  (7)  depicts  the  MDS  subsystem. 


(3)  Supply  and  F inane ial  Management  (SFM) . 


The  Supply  and  Financial  Management  Subsystem  (SFM)  pro¬ 


vides  support  for  those 
to  supply  and  financial 
ordering  and  monitoring 
budgeting  and  reporting 


funct ions  specifically  related 
management,  including  parts 
inventory  management  and  financial 
[Ref.  1 1 : p .  3 ] 


Figure  (8)  depicts  the  SFM  subsystem. 

(4)  Administrative  Data  Management  (ADM).  This 


subsystem  provides  support  for  administrative  functions 
relating  to  personnel  management.  Figure  (9)  depicts  the 
ADM  subsystem.  This  subsystem's  programs  include  the 
following : 

-  control  of  berthing  assets 

-  assignments  to  lifeboats 

-  personnel  assignments 

-  watch  bill  preparation  and  coordination 

-  personnel  school  data 

-  security  information  on  personnel 

-  department/division  records 

-  immunization  status  of  personnel 

-  medical  examination  status 

-  medical  and  dental  appointment  control 

-  advancement  and  career  counselor  data 

-  prospective  gains/losses 

( 5 )  Mobile  Logistics  Support  Fo rce  (MLS 

The  MLS  automated  data  processing  system  interfaces  and 
supports  the  replenishment  functions  aboard  AE,  AO,  AOE , 
and  AOR  class  ships.  It  automates  all  Special  Accounting 
Class  (SAC)  224  material  handling  processes,  including 
producing  necessary  reports.  Additionally,  it  interfaces 
with  the  Underway  Replenishment  (UNREP)  system  on  board 
AFS's  and  produces  fleet  commander  statistical  reports. 

[ Ref .  1 : p .  16 ] 

2 .  Fleet  Introduction  of  Software 

NAVMASSO  Introduces  software  to  the  fleet  by  the 
following  methods: 


-AV • 


SUPPLY  AND  FINANCIAL  MANASEWNT  SUBSYSTEM 
FIGURE  8 
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-  implementation  on  ships  without  SNAP- 1 1 

-  back  fit  of  new  releases  on  ship's  with  SNAP- II 

-  interim  changes  to  existing  programs 

Implementation  and  back  fit  of  releases  are  accomplished  by 
NAVMASSO  personnel.  NAVMASSO  uses  releases  to  introduce  new 
subsystems  or  major  changes  to  existing  programs.  Interim 
changes  (updates)  to  programs  are  forwarded  to  the  ships  by- 
mail  and  the  ship's  System  Coordinator  loads  the  update  into 
the  SNAP- 1 1  system.  A  summary  of  software  releases  is 
provided  for  historical  perspective. 

a.  Initial  release 

(1)  Maintenance  Data  Subsystem  (MDS) .  The  initial 
release  provided  the  user  with  the  basic  programs  to  process 
maintenance  actions  into  the  Ship's  Force  Work  List  (SFWL) 

and  the  ability  to  enter  data  used  to  generate  supply  material 
requ i rements  for  both  internal  and  off-ship  processing. 

(2)  Supply  Financial  Management  (SFM).  The 
initial  release  provided  the  user  with  limited  automated 
support  for  parts  ordering  and  monitoring,  inventory  management 
and  financial  budgeting  and  reporting. 

(5)  System  Management  Subsystem  (SMS).  The 
initial  release  provided  control  over  all  subsystems  and  user 
ability  to  review  the  on-line  User  Manual's. 

b.  Release  2 

(1)  MDS.  This  release  added  programs  for  Current 


Ship's  Maintenance  Project  (CSMP),  completing  maintenance 
actions  (Ck  generation),  test  equipment  calibration  function 


(MEASURE),  Ship's  Equipment  Pile  (SEE)  and  an  expanded 
Technical  Document  (TECDOC1  Module. 

(2)  SFM.  This  release  added  proprams  for  on-line 
requisition  status  processing ,  requisition  hi  store  processing 
Requisition  Status  file,  Requirements  Report  and  enhancement s 
to  reports. 

(a)  Adm  inistr.it  ive  Data  Management  AlV  ■ 
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(1)  MDS .  This  release  added  a  program  for  bulk 

CSMP  input. 

(2)  SFM.  This  release  provided  enhancements  to 
financial  program  reports,  requisition  processing,  and 
inventory  reports. 

(3)  ADM,  SMS,  MLS.  This  release  provided 
enhancements  to  provide  greater  accessibility  and  capability 
to  existing  programs.  (Mobile  Logistics  Support  (MLS) 
program  was  added  as  part  of  an  update  to  Release  2) . 

e.  Approved  Software  Changes  to  SNAP- 1 1 

The  following  are  the  planned  modifications  to 
existing  programs  and  additional  programs  that  have  been 
approved  for  implementation: 

( 1 )  Release  5 

Release  5  is  projected  to  be  introduced  in 
FY  198b.  The  programmed  modifications  are  as  follows: 

-  SFM  Transaction  Ledger 

-  SFM  I nvcntory / F inane ia 1  Audit  Trail 
SFM  Inventory  Level  Setting 

-  MDS  Automated  COSAL  Maintenance 

-  MDS  Multiple  COSAL  Support 

( 2 )  Release  b 

-  SFM  DLR  Carcass  Tracking  System 

-  I.OCMARS  receipt  processing 

-  Submarine  suppl y/ f inane ial 

-  F f f ec t  i venes s  Report 

f.  Future  Planned  Applications 

-  Training 

Planned  Maintenance  System  (PMS) 

Aviation  Maintenance  Subsystem  (AMS) 

-  Light  Airborne  Multipurpose  System  (LAMPS) 
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-  Logistics  Application  of  Automated  Marking  and 

Reading  Symbols  (LOGMARS) 

-  Food  Services 

-  Retail  operations 

-  Medical  and  dental 

-  Source  Data  System  Afloat  (SDSA) - -Disbursing  and 

Personnel 

-  Ship's  Force  Overhaul  Management  System  (SFOMS) 

-  Technical  Library 


D.  PERSONNEL 

1 .  Concept  of  Manning 

The  design  and  concept  of  the  SNAP- 1 1  System  is 
predicated  on  the  requirement  that  no  additional  personnel  be 
required  to  manage,  operate  or  maintain  the  system  [Ref.  2: 
p.  II,  and  that  these  duties  be  performed  by  existing  ship¬ 
board  personnel  on  a  collateral  duty  basis. 

Both  Atlantic  and  Pacific  fleet  surface  Type 
Commanders  have  issued  instructions  [Ref.  ll:pp.  3-6],  [Ref. 

1 2 : Enc 1 .  (1)  pp .  2-4]  delineating  specific  system  responsi¬ 
bilities.  Both  closely  follow  the  Management  Guide  issued 
by  YUMA  S  SO  [Ref.  1  :  pp  .  20-  24  ]. 

The  following  collateral  duty  billets  are  identified: 

-  System  Coordinator 

-  Assistant  System  Coordinator 

-  Functional  Area  Supervisors 

-  Hardware  Maintainors 

2  .  Specific  System  Requirements/Assignments 
a.  System  Coordinator 

An  officer  or  chief  petty  officer  will  be 
responsible  for: 

-  implementation,  operation,  and  maintenance  of  the  system 

-  primary  point  of  contact  for  the  ship 


-  coordinate,  monitor,  and  schedule  system  usage  by 

Functional  Area  Supervisors 

-  perform  backup,  recovery  and  update  procedures 

-  system  security  and  integrity  of  data  bases. 

b.  Functional  Area  Supervisors  (FAS) 

Each  subsystem  implemented  on  board  a  ship  will 
have  a  Functional  Area  Supervisor.  The  FAS  will  be  an 
officer  or  senior  petty  officer  whose  skills  and  knowledge 
in  that  area  qualify  them  for  such  designation.  His 
responsibilities  include: 

-  ensuring  integrity  of  data  base 

-  ensuring  security  procedures  are  followed 

-  assigning  access  to  personnel 

-  conducting  training  for  all  users 

-  being  responsible  for  implementing  all  facets  of  his 

functional  area 

c.  Hardware  Maintainers 

The  Hardware  Maintainers  are  rated  Electronics  or 
Data  Systems  Technicians,  with  two  specified  per  installation. 
The  Hardware  Maintainers  are  responsible  to  the  System 
Coordinator  for  the  preventive  and  corrective  maintenance  on 
the  SNAP- 1  I  system. 

d.  Users 

The  Managment  Guide  and  Type  Commander  instructions 
specify  two  types  of  users:  journeyman  and  basic.  Basic 
users  will  normally  only  perform  data  entry  and  retrieval 
operations  for  a  specific  task  within  one  functional  area. 
•Journeymen  users  have  more  capabilities  in  the  system,  and 
have  the  capability  to  perform  multiple  tasks  within  a 
functional  area  or  can  have  access  to  more  than  one  functional 
area,  as  designated  by  the  Commanding  Officer. 
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E.  TRAINING 


I .  Concept 

SNAP- I  I  training  has  been  conceptual  iced  as  a  two- 
phased  approach- - initial  and  follow  on  training,  with  each 
of  these  sub-categorized  as  to  whether  it  is  conducted  on 
board  or  off-ship  [Ref.  15:pp.  146-150].  Table  IV  illustrates 
this  concept. 

The  initial  training  is  conducted  during  the  initial 
implementation  of  the  system  on  a  ship.  This  is  performed 
by  NAVMASSO  (Systems  Coordinators  and  on  board  user  training) 
and  by  SMA  (Ma inta iners ) .  NAVMASSO  will  conduct  all  initial 
implementation  training,  whereas  maintainers  training  will 
transition  to  FTC  Norfolk  and  FTC  San  Diego  at  some  point  in 
the  future. 

Follow  on  training  is  to  be  the  responsibility  of  the 
Navy  training  establishment,  with  10  (possibly  12)  commands 
identified  to  conduct  this  training  [Ref.  13:p.  12b].  Pro¬ 
jected  Navy-wide  training  and  education  programs  will  involve 
the  assignment  of  NEC's  to  various  system  personnel, 
development  of  PQS  and  on  board  training  materials  for  the 
various  functional  areas  and  self-study  workbooks  [Ref.  13: 
pp .  160- 164 ] . 


Follow  on  training  on  board  ships  is  a  ship 
responsibility,  with  training  materials  to  be  provided. 


TABLE  IV 


SNAP- 1 1  TRAINING 


ON  SHIP 


OFF  SHIP 


Initial  ■ Implementation  training 
I  by  NAVMASSO 


Maintainers  (SMA) 

Ship  System  Coord¬ 
inators  (NAVMASSO 

PCO/PXO  (NAVMASSO) 


Follow  on  |  Not  specified  (ship's 

Maintainer  (May  8b 

]  responsibility) 

RFT)  PCS  Pipeline 

Ship  System  Coord- 

I 

i 

inator  (TAD/PCS) 

l 

PCO/PXO  (FTC's) 

1 

3-M  Systems  Coo"d- 

1 

inator 

l 

l 

1 

Leading  Storekeeper 

1 

1 

SNAP  Admin  Mgt  Super 

i 

i 

SWOSCOL  for  CO/XO/ 

i 

l 

DH/DO 

Z .  Training 

In  the  initial  and  follow  on  training  phases,  specific 
formal  training  courses  are  provided  for  the  following 
personnel : 

-  Systems  Coordinator 

-  Hardware  Maintainer 

*  -  5-M  Coordinator 

*  -  leading  Storekeeper  Afloat 

*  -  SNAP- II  Administrative  Management  Supervisor 

*  not  implemented  as  of  31  January  1986 

Surface  Warfare  Officers  training  is  to  be  included  as  an 
adjunct  to  the  PCO,  PXO,  Department  Head  and  Basic  courses 
conducted  by  SWOS,  although  this  has  not  formalized  and  in 
place  as  of  January  1986.  There  is  no  mention  of  Submarine 
Officer  training.  Training  for  Supply  Officers  is  being 
conducted  at  NSCS,  Athens,  Ga. 

Training  materials  for  on  board  initial  and  follow 
on  training  are  prescribed  in  the  Navy  Training  Plan  as  well. 
They  include  training  for  Journeyman/Basic  User  and  Functional 
Area  Supervisors  for  initial  training,  and  the  following  for 
follow  on  training  (for  each  subsystem)  [Ref.  15:pp.  163-164]: 

-  Functional  Area  Supervisor  Trainee  Guides 

-  Journeyman/Basic  User  Instruction  Guides  and  Trainee 

Guides 

-  Self-Study  Workbooks 
3 .  Transition 

The  transition  process  has  experienced  some  delays. 
Approval  of  the  Navy  Training  Plan  was  dated  1  April  1985, 
almost  two  years  after  the  first  SNAP- 1 1  installation  on  a 
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Currently,  NAVMASSO  is  the  primary  agent  for 
conducting  SNAP- 1 1  training.  In  accordance  with  the  Navy 
Training  Plan  for  SNAP-II  [Ref.  13],  full  transition  to 
follow  on  training  was  scheduled  for  Calendar  Year  1986. 

Some  training  establishments  already  have  instituted  some 
SNAP-II  training  (NSCS,  Athens;  SWOS) .  The  planned  "ready 
for  training"  dates  are  contained  in  the  Navy  Training  Plan 
[Ref.  13:p.  126].  Various  sources  have  indicated  that  these 
dates  may  not  be  realistic  and  may  slip. 
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IV.  CASE  STUDIES 


In  order  to  ascertain  the  end  users  views  and  concerns 
with  the  SNAP- II  system,  six  ships  were  visited  and  inter¬ 
views  conducted  with  key  personnel.  The  interviews  were 
both  structured  and  unstructured,  depending  on  the  response 
of  the  individual  interviewed. 

A  "topdown"  concept  of  interviewing  was  selected  so  as  to 
obtain  a  valid  organizational  picture.  Data  entry  users  were 
excluded  from  the  interview  process  because  of  time  and 
personnel  limitations  and  the  narrow  view  data  entry  personnel 
would  have  of  the  system.  The  assumption  was  that  problems 
or  concerns  at  the  lowest  level  would  be  evident  at  the  next 
higher  level  or  levels  because  of  the  highly  structured 
organizational  hierarchy  inherent  on  a  U.S.  Navy  ship. 

Three  levels  of  personnel  were  interviewed:  the  command 
level  personnel  (Commanding  Officer  and  Executive  Officer), 
Department  Heads,  and  the  personnel  responsible  for  actual 
system  operation  and  maintenance  (System  Coordinator, 
Functional  Area  Supervisors,  and  Hardware  Maintainors). 

The  results  of  the  various  interviews  are  presented  in 
the  following  six  case  studies,  or  reviews.  The  comments  and 
observations  of  the  ships  personnel  are  presented  without 
comment  from  the  authors.  Summaries  and  specific  commentary 
are  presented  in  the  Chapters  following  the  case  reviews. 


1  a 


1 .  Introduction 

The  SNAP- 1 1  system  was  installed  during  January  of 
1984  on  this  Guided  Missile  Cruiser  homeported  on  the  West 
Coast.  Full  transition  to  SNAP- II  occurred  in  February,  just 
prior  to  and  during  the  initial  at  sea  period  of  a  major 
forward  deployment  to  the  Western  Pacific.  Prescribed  user 
training  for  shipboard  personnel  was  conducted  underway  while 
enroute  to  the  first  port  visit  of  the  deployment. 

There  was  very  positive  command  support  during  the 
installation  and  implementation  of  the  system.  Of  the  data 
bases  (WSF,  personnel,  CSMP)  that  were  loaded  at  implementation 
various  pieces  of  information  were  missing,  causing  some 
degree  of  user  mistrust  at  the  outset.  Subsequently,  the 
ship  has  experienced  a  minimum  of  problems  with  the  system, 
due  to  strong  user  and  management  involvement  and  excellent 
support  from  NAVMASSO  and  NAVSEACENPAC . 

Figures  (1)  and  (2)  in  Chapter  II  delineate  the 
integration  of  the  SNAP-II  system  operational  and  maintenance 
responsibilities  within  the  ships  internal  organization.  A 
Senior  Chief  Petty  Officer  (SKCS)  from  the  Supply  Department 
is  assigned  as  the  System  Coordinator,  with  the  ship's  5-M 
Coordinator,  a  Chief  Petty  Officer  (EMC),  as  the  assistant 
coordinator.  The  assistant  is  also  assigned  as  the  Func t i ona 1 
Area  Supervisor  for  the  MDS  subsystem.  The  same  SKCS  is  also 
assigned  as  the  Functional  Area  Supervisor  for  the  SFM 


subsystem,  with  the  Supply  Officer  strongly  involved.  A  first 
Class  Petty  Officer  (PM!  is  the  FAS  for  the  ADM  subsystem. 

Hardware  maintenance  is  performed  by  Data  System 
Technicians  (DS  rating) ,  although  the  administration  of  the 
maintenance  activities  is  under  the  cognizance  of  the 
Electronic  Technician  workcenter.  This  evolved  because  the 
ship's  Electronic  Technicians  (ET  rating)  originally  performed 
the  maintenance,  but  for  various  uncited  reasons,  this 
responsibility  was  shifted  to  the  Data  System  Technicians. 

The  hardware  installed  is  in  accordance  with  the  specifications 
for  a  ship  of  her  class  and  size. 

Training  for  users  is  centrally  managed  and  scheduled 
through  the  weekly  meeting  of  the  ship's  Planning  Board  for 
Training.  The  actual  training  sessions  are  conducted  by  the 
individual  Functional  Area  Supervisors. 

The  ship  is  currently  using  version  4.00.06  of  the 
SNAP-II  software,  with  version  4.00.07  on  board  and  awaiting 
installation.  SNAP-II  is  considered  an  integral  part  of  the 
internal  adminst rat  ion  of  this  ship  and  is  strongly  supported 
and  used  at  all  levels  of  the  cha in  -  of  -  command .  It's  use  is 
so  widespread  that  system  backups  are  planned  carefully  and 
receive  high  level  attention  so  as  not  to  interfere  with  the 
users . 

2 .  Command  Perception 

The  Commanding  Officer  had  been  in  command  for  six 

months  at  the  time  of  the  interview.  He  had  not  been  aboard 
during  installation  and  implementation  of  the  system. 


The  Captain  spoke  highly  of  the  SNAP- 1  I  system  and 

indicated  that  it  was  used  extensively  by  all  levels  in  his 

command.  Summarizing  his  feelings,  he  stated: 

Quick  and  dirty,  I  love  it.  I'm  a  supporter  of  SNAP  - 1 1 
and  it's  used  extensively  on  board  the  ship  for  other 
things  .  .  .  sometimes,  we  get  carried  away. 

The  Captain  attributed  the  successful  implementation 
of  the  system  to  the  talent  and  dedication  of  the  various 
users  and  managers,  feeling  that  a  ship  without  the  resources 
he  had  probably  would  not  fare  as  well.  Because  of  the 
talented  people  on  board,  he  felt  that  they  were  able  to  do  a 
great  deal  of  learning  and  experimenting  for  themselves, 
which  had  led  to  less  dependence  on  formalized  training  to 
successfully  integrate  the  system  into  the  ship's  routine. 

The  right  people  with  the  right  attitude  was  the  key  to 
success. 

The  Captain  expressed  his  views  about  the  impact  of 
the  system  on  his  command  from  several  perspectives.  One  was 
the  proliferation  of  information  available,  and  the  other  was 
the  positive  effect  on  the  management  of  his  ship. 

a.  Management 

The  accuracy  and  timeliness  of  reports  available 
from  the  SNAP- 1 1  system  was  the  key  ingredient  that  the 
Captain  felt  had  contributed  in  a  positive  manner  to  the 
internal  management  of  his  command.  He  was  most  enthusiastic 
about  the  MDS  subsystem  and  its  ability  to  maintain  and 
provide  accurate  information  about  the  ship's  maintenance 


activities  through  the  CSMP  (Current  Ships  Maintenance 
Project)  reports.  The  savings  in  man-hours  in  data-entry  and 
the  timeliness  of  obtaining  reports  in  comparison  with  the 
former  manual  method  and  dependence  on  external  ADP  activities 
was  significant: 

The  last  time  I  was  at  sea,  you  never  got  it  right  (the 
CSMP),  because  by  the  time  it  came  back  from  the  Type 
Commander,  a  month,  6  weeks  had  elapsed  and  you  were 
always  behind--you  could  never  pick  up  the  CSMP  and  say, 

' this  isIT'. 

The  Captain  felt  that  the  ability  of  his 
Department  Heads  to  effectively  manage  was  enhanced  because 
they  were  able  to  obtain  and  rely  on  information  that  had  not 
previously  been  utilized  to  its  full  extent.  He  did  not 
indicate  that  the  style  or  manner  of  management  had  changed, 
only  that  previous  methods  and  procedures  had  been  strengthened 
through  the  use  of  SNAP- generated  information.  As  an  example, 
he  cited  the  ease  with  which  the  ship  had  been  able  to  under¬ 
go  an  INSURV  inspection  (INSURV  is  the  acronym  for  the  Navy 
Board  Of  Inspection  and  Survey,  an  independent  activity  that 
reports  to  the  CNO  on  the  material  condition  of  ships).  The 
ease  and  accuracy  with  which  material  discrepancies  had  been 
documented  and  acted  on  was  a  direct  result  of  being  able  to 
have  an  accurate  CSMP  instantaneously  available  for  management 
to  work  with  and  plan  for  remedial  action. 

Although  the  Captain  had  a  great  deal  of 


enthusiasm  for  the  system,  he  did  not  have  a  terminal  in  his 
cabin,  nor  did  he  want  one.  He  felt  that  his  having  one  would 


border  on  "micro-managing"  his  subordinates. 


If  he  wanted 


information  about  anything,  he  would  do  as  he  had  done  in  the 
past--summon  the  person  responsible  and  ask  for  the  information, 
b.  Prol iferation  of  Information 
.  .  .  sometimes  we  get  carried  away  .  .  . 

In  some  cases,  the  Captain  felt  that  he  had 

available  too  much  information;  more  than  he  could  use.  He 

cited  as  an  example  the  ship's  8  o'clock  reports  (reports 

forwarded  to  the  Commanding  Officer  by  the  individual 

departments  about  their  material  condition  at  8  PM  each  day) : 

.  .  .  in  some  cases  they're  giving  me  more  information  than 
I  need,  but  after  a  while  you  learn  where  to  look.  Some  8 
o'clock  reports  from  a  department  will  be  four  pages  long, 
because  they'll  have  everything  there,  whereas  before  we 
used  to  say,  'what  got  broke,  what  broke  today,  and  what 
got  fixed  today.'  So,  we're  adding  a  summary  sheet  on 
top  of  the  whole  pile. 

3 .  Middle  Level  Management  and  SNAP- 1 1 

The  term  "middle  level  managers'  applies  to  those 
officers  in  charge  of  the  various  departments  on  the  ship. 

Those  officers  interviewed  included  the  Operations  Officer, 
the  Combat  Systems  Officer,  the  Supply  Officer,  and  an  officer 
representing  the  Engineering  Officer.  The  Engineering  Officer 
was  not  interviewed  because  he  had  been  on  board  a  relatively 
short  period  of  time,  and  the  officer  designated  could  provide 
a  better  insight  with  respect  to  that  department. 

Of  the  Department  Heads,  only  the  Supply  Officer  had 
a  background  in  computer  systems,  having  a  B.S.  degree  in 
Data  Processing.  None  of  them  had  any  prior  experience  with 
nor  any  formal  training  on  the  system. 


As  a  group,  these  officers  mirrored  the  Commanding 
Officer's  opinion  that  the  SNAP- 1 1  system  was  a  significant 
management  tool,  indicating  that  they  themselves  and  the 
personnel  in  their  departments  used  not  only  the  specific 
reports  the  system  provided,  but  were  also  adapting  the  word 
processing  system  and  mail  facilities  to  their  personal  needs 
to  save  time,  communicate,  and  produce  their  own  reports. 

The  benefits  derived  from  the  SNAP- 1 1  system  were  not 
quantifiable  in  an  objective  manner,  but  subjectively  these 
officers  felt  that  the  efficiency  of  their  departments  was 
enhanced.  Personnel  were  spending  less  time  preparing 
maintenance  and  supply  documents,  getting  faster  responses 
from  the  supply  system,  and  in  general  were  more  accurate  in 
what  data  they  were  entering  to  the  system.  Because  of  the 
increased  accuracy ,  faster  response  and  the  reports  available 
managers  at  all  levels  were  able  to  manage  more  effectively. 

Although  these  officers  did  not  indicate  that  SNAP- 1 1 
has  changed  their  management  style,  one  officer  did  note  that 
since  implementing  the  system,  there  has  been  a  proliferation 
of  formal  ship's  Notices.  These  Notices  gave  formal 
instruction  for  the  conduct  of  specific  ship's  evolutions 
that  had  in  the  past  been  promulgated  verbally  or  through  the 
Plan  of  the  Day,  which  is  a  daily  schedule  of  the  ship’s 
routine  and  special  events. 

As  a  group,  these  officers  were  uniformly  pleased 
with  the  SNAP- 1  I  system,  considering  it  a  vast  improvement 


over  the  former  manual  methods.  Their  enthusiasm,  however, 
did  not  blind  them  to  problems  with  the  system  or  improvements 
they  felt  should  be  incorporated.  These  concerns  were  in  the 
following  areas: 

-  documentat  ion 

-  training 

-  system  Improvements 

a.  Documentation 

System  documentation  was  not  helpful  from  the 
middle-managers  point  of  view,  in  contrast  with  little 
objection  or  complaint  being  reported  from  the  personnel  who 
use  the  system  for  data  entry.  Asked  whether  they  found  the 
documentation  easy  to  use  and  effective  in  acquainting  them 
with  the  capabilities  of  the  system,  these  officers  responded 
negatively  across  the  board. 

The  main  thrust  of  their  complaints  was  that  the 
documentation  did  not  give  them  an  adequate  overview  of  the 
system  and  that  it  was  not  written  in  terms  that  they  could 
readily  understand.  As  a  result  of  this,  they  reported  that 
experience  was  the  best  teache r- - they  had  to  use  the  system 
extensively  in  order  to  understand  and  be  familiar  with  the 
documenta  t  ion . 

b.  Training 

Training  system  users  is  a  well  coordinated  and 
executed  evolution,  with  the  only  negative  comments  directed 
at  the  initial  implementation  training,  which  had  been 
conducted  underway  enroute  to  a  major  deployment. 


Recommendations  for  follow-on  training  was  the 
main  point  that  the  Department  Heads  had,  as  there  is  presently 
none  available  on  a  formal  basis,  nor  are  training  aids 
provided  for  shipboard  use.  The  following  suggestions  were 
provided : 

-  development  of  interactive  training  programs  for  users 

-  development  of  various  video-taped  training  programs 

-  develop  a  shipboard  training  package 

-  provide  a  waterfront  training  program  similar  to  ones 

that  exist  for  3-M  and  Damage  Control  Petty  Officers-- 
i.e.,  a  short  (five  days  or  less)  class  scheduled  and 
conducted  locally 

c.  System  Improvements 

The  Department  Heads  expressed  ideas  on  how  to 
improve  the  system  and  add  new  applications.  For  reasons 
that  were  not  clear  (perhaps  not  being  familiar  with  the 
administration  of  the  SNAP- 1 1  system),  few  of  these  have  been 
formally  requested  through  official  channels  via  the  "Change 
Proposal"  mechanism  provided  for  in  the  Type  Commanders 
directive  concerning  the  administration  of  the  SNAP-II  system. 
Most  of  the  suggestions  related  to  producing  formatted  reports, 
such  as  CASREPS  (reports  of  equipment  casualties)  and  enlisted 
evaluations,  and  as  such  will  not  be  listed  here. 

4 .  System  Operation  and  Management 

The  following  personnel  are  assigned  SNAP-II  system 
responsib il it ies  : 

-  System  Coordinator- - SKCS  (also  the  SFM  FAS) 

-  Assistant  System  Coordinator- -  EMC  (Also  the  MDS  FAS) 

-  ADM  FAS--PN1 
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The  choice  of  these  individuals  was  fortunate- -with  the 
exception  of  the  MDS  FAS,  there  was  a  high  degree  of  computer 
system  knowledge.  The  SKCS  had  an  Associate  Degree  in  the 
computing  field,  and  the  PNl  had  nine  years  experience  working 
with  computer  systems  in  various  shore  duty  assignments.  None 
of  these  individuals  had  any  experience  with  the  SNAP- II 
system  prior  to  their  present  tour  of  duty, 
a.  Maintenance 

Hardware  maintenance  is  performed  by  Dat  i  System 
Technicians  (DS  rating),  who  felt  that  the  training  received 
was  good,  and  that  the  technical  documentation  was  more  than 
adequate  for  them  to  perform  their  duties. 

One  concern  expressed  by  the  maintainors  (and 
supported  by  the  System  Coordinator)  was  the  location  of  the 
SNAP-II  computer  itself.  It  is  located  directly  over  the 
after  engine  room  and  cooling  could  be  a  problem.  Any  dis¬ 
ruption  of  air-conditioning  service  to  the  space  would  mean 
a  rapid  rise  in  the  ambient  temperature,  and  it  was  recommended 
that  an  interlock  between  the  computer  and  the  air-conditioning 
be  installed  to  prevent  heating  problems  and  system  crashes. 

In  this  manner,  "graceful"  system  degradation  could  occur, 
giving  users  ample  time  to  save  their  files. 

Maintaining  the  system  on  a  collateral  duty  basis 
did  not  present  a  particular  problem  in  terms  of  coordination 
or  workload,  just  in  the  question  of  when  the  maintenance  is 
performed.  Because  of  the  heavy  use  of  the  system,  any 


preventive  maintenance  has  to  be  done  after  working  hours, 
and  often  late  at  night. 

b.  System  Coordinator  and  SFM  FAS 

The  system  coordinator  felt  that  the  formal 
training  he  received  from  NAVMASSO  was  "too  fast",  indicating 
that  he  had  barely  assimilated  system  terminology  before 
instruction  had  moved  into  the  operational  aspects  of  the 
system.  Despite  this  initial  drawback,  he  had  not  experienced 
problems  in  actually  running  and  managing  the  system.  He  felt 
he  had  a  good  understanding  of  the  system  and  his  responsi¬ 
bilities,  and  he  interacted  well  with  all  levels  of  system 
users  and  managers  within  the  ship. 

The  Senior  Chief  had  not  experienced  any  problems 
with  the  system  documentation,  and  felt  that  the  SMS  subsystem 
was  performing  adequately. 

In  the  SFM  subsystem,  his  only  recommendation  for 
change  was  the  inclusion  of  a  Storekeeper  (SK)  training  manual. 
While  he  considered  the  documentation  adequate  for  use  of  data 
entry  personnel,  he  wanted  his  people  to  understand  what  was 
happening  "inside"  the  program,  and  as  such  needed  a  good 
training  document  to  guide  him. 

Hardware  maintenance  was  considered  more  than 
adequate,  with  no  problems  reported  in  scheduling  or 
executing  maintenance.  As  far  as  the  hardware  was  concerned, 
the  only  major  issue  was  the  lack  of  enough  user  terminals. 


The  Senior  Chief  did  have  ideas  on  system 
improvements  in  the  SFM  area,  although  he  did  not  indicate 
that  these  ideas  had  been  formally  submitted  as  "change 
proposals"  up  the  chain-of-command.  Most  of  his  recommendations 
concerned  specific  details  of  entering  and  retrieving  individual 
items  of  data  and  formatting,  and  will  not  be  listed  here. 

Overall,  The  Senior  Chief  was  pleased  with  the 
system  and  had  nothing  but  praise  or  constructive  comments 
to  make. 

c.  Assistant  System  Coordinator  and  MDS  FAS 

Although  not  having  a  computer  background  as  the 
other  key  personnel  in  SNAP- 1 1  management,  the  MDS  FAS  was 
comfortable  in  his  job  and  had  a  good  working  knowledge  of 
the  system  and  his  particular  subsystem.  He  had  the  most  to 
say  about  the  specific  functions  of  the  system  during  the 
course  of  the  interviews,  perhaps  due  to  his  excellent  know¬ 
ledge  of  the  3-M  system  and  his  desire  to  make  the  subsystem 
mirror  his  capability  and  knowledge  about  procedures  and 
requirements  in  the  3-M  system. 

In  the  area  of  system  training,  the  MDS  FAS 
recommended  that  formal  training  be  set  up  for  the  functional 
area  supervisors.  In  this  manner,  they  could  become  the 
system  "experts"  prior  to  assuming  the  job,  instead  of  having 
to  learn  as  they  went  along,  and  not  have  to  rely  on  what 
their  predecessors  in  the  job  had  passed  on  (or  neglected  to 
pass  on)  in  the  course  of  the  relieving  process. 
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The  Chief  was  generally  pleased  with  the  performance 
of  all  aspects  of  the  MDS  subsystem,  and  indicated  that  the 
success  of  the  system  was  partially  due  to  the  strong  5-M 
system  that  was  in  place  on  the  ship  prior  to  the  implemen¬ 
tation  of  SNAP-II.  To  this  end,  he  noted  that  there  is  no 
guidance  from  the  3-M  system  (Documentation)  on  the  subject 
of  how  to  integrate  the  SNAP-II  system  to  it,  and  that  this 
had  caused  some  minor  problems  in  dealing  with  the  shore 
maintenance  establishment. 

Overall,  the  system  documentation  was  felt  to  be 
adequate,  with  the  on-line  user  "help"  feature  considered  a 
major  contributor  to  the  accuracy  achieved  by  the  data  entry 
personnel . 

System  hardware  was  considered  excellent,  with 
the  floppy  disks  being  the  only  problem  area  identified.  They 
were  considered  unreliable  to  use  because  of  problems  in  data 
transfer- - sometimes  they  did,  sometimes  they  didn't--and  as 
such  were  not  used.  This  problem  had  been  identified  to 
NAVMASSO,  but  no  action  had  been  taken  to  date. 

In  summary,  the  Chief  was  satisfied  with  the 
system,  although  he  had  pointed  our  various  instances  of 
software  "bugs".  He  felt  that  the  system  had  been  integrated 
successfully  into  the  ship's  routine  and  that  it  was  being 
used  to  it’s  full  extent, 
d.  ADM  FAS 

Despite  a  slow  start  in  system  use  after 
implementation  because  of  slow  response  times  and  problems 


with  the  personnel  data  base,  the  ADM  FAS  rated  the  system  as 
"good",  and  would  like  to  see  new  additions  to  the  program, 
such  as  the  ability  to  generate  enlisted  evaluations.  He 
reported  that  the  "query"  function  of  the  subsystem  was  used 
extensively,  and  that  the  personnel  that  worked  for  him  were 
using  the  system  in  a  satisfactory  manner. 

System  documentation  was  not  an  issue,  as  the 
personnel  using  the  ADM  subsystem  relied  heavily  on  the  on¬ 
line  "help"  feature  to  guide  them  in  lieu  of  using  any  written 
documentation.  The  initial  training  of  personnel  was  not  an 
issue,  nor  was  the  subject  of  ongoing  training. 

Training  for  the  FAS  himself  was  the  major  issue 
he  raised,  indicating  a  need  for  formal  training  before 
assuming  the  job.  This  would  ensure  a  proper  "turnover"  when 
one  person  relieved  another  on  the  job,  and  insure  a  continuity 
of  knowledge  and  adequate  leadership  and  management. 

B.  CASE  2 

1 .  Introduction 

The  SNAP-II  system  was  installed  in  two  phases  on 
this  Guided  Missile  Cruiser  homeported  on  the  West  Coast. 
Normally,  installation  is  scheduled  for  a  single  time  frame, 
but  in  this  instance  it  was  split.  This  was  due  to  the  ship's 
desire  to  accelerate  the  process  in  anticipation  of  the 
upcoming  operational  schedule,  which  would  have  otherwise 
dictated  the  installation  at  a  much  later  point  in  time. 


With  the  concurrence  of  the  Type  Commander  and  the 
SNAP-II  project  manager,  the  initial  hardware  installation 
was  performed  in  December  of  1983  while  the  ship  was  nearing 
the  completion  of  a  regularly  scheduled  overhaul.  Because  of 
the  accelerated  installation  and  due  to  the  unavailability 
of  resources,  only  seven  of  14  user  terminals  were  installed. 

After  completion  of  the  first  phase  of  installation, 
the  ship's  manual  records  and  documents  were  converted  to 
electronic  media,  and  version  2.0  of  the  application  software 
was  installed,  with  the  system  becoming  operational  in  March 
of  1984.  There  were  no  major  problems  associated  with  the 
records  conversion,  although  the  conversion  of  COSAL  records 
was  incomplete,  possibly  due  to  the  fact  that  the  SOAP  team 
validation  of  the  existing  COSAL  had  not  been  completed.  Some 
initial  training  delays  were  experienced  because  of  the  lack 
of  enough  terminals  and  an  insufficient  amount  of  system 
documentation  manuals  (only  two  user  manuals  available  vice 
one  for  each  terminal). 

The  second  phase  of  hardware  installation  was  planned 
for  a  period  of  three  weeks  during  August/September  1984, 
with  an  upgrade  to  version  4.0  of  the  software  scheduled  for 
the  same  period.  This  wrork  fell  behind  schedule  by  several 
weeks,  requiring  the  ship  to  put  to  sea  on  routine  operations 
with  a  "down"  SNAP-II  system.  This  disrupted  the  ship's 
ability  to  process  standard  maintenance  and  supply  documents, 
of  which  they  had  now  come  to  depend  for  entirely  on  the 
SNAP-II  system. 
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At  the  time  of  the  interview,  the  ship  had  the 
standard  SNAP-II  hardware  configuration  for  a  ship  of  her 
class  and  size,  and  had  version  4.00.07  of  the  software 
installed . 

The  attitude  prevalent  in  the  ship  throughout  the 
installation  and  implementation  phase  was  positive;  the 
command  had  been  insistent  on  doing  things  right  the  first 
time.  Since  coming  on  line,  the  ship  has  experienced  few 
problems  with  either  the  software  or  hardware.  This  system 
is  considered  to  be  very  rugged  and  reliable,  with  satisfactor 
results  being  achieved. 

Figures  (1)  and  (2)  in  Chapter  II  delineate  the 
integration  of  the  SNAP-II  system  operational  and  maintenance 
responsibilities  within  the  ship's  internal  organization. 

The  Assistant  Supply  Officer  has  been  designated  as  the  System 
Coordinator,  with  a  Chief  Petty  Officer  from  the  Supply 
Department  (an  SKC)  assigned  as  his  assistant.  Maintenance 
on  the  hardware  is  performed  by  a  Data  Systems  Technician  (DS) 
who  is  normally  responsible  for  the  operation  and  maintenance 
of  the  ships  NTDS  computers,  and  a  Postal  Clerk  (PC).  The 
Functional  Area  Supervisors  are  assigned  in  accordance  with 
the  directives  of  the  Type  Commander,  Commander  Naval  Surface 
Forces,  Pacific  Fleet  (COMNAVSURFPAC)  [Ref.  12:Encl.  (1), 
pp .  2  -  4 ] . 

SNAP-II  appears  to  be  successfully  implemented  in 
this  ship,  although  not  all  facets  of  each  subsystem  are 


being  fully  utilized.  The  system  is  well  accepted  throughout 
the  ship,  and  has  apparently  not  caused  any  radical  changes 
in  the  way  the  ship  manages  or  conducts  its  business.  To 
date,  there  has  been  no  effort  to  write  individual  software 
programs  using  the  system's  BASIC  language  programming 
capability,  partly  due  to  the  perception  that  the  system  is 
already  heavily  loaded,  and  due  to  a  lack  of  BASIC  language 
documentation  and  training. 

There  is  no  formal  training  program  in  place  to  teach 
system  familiarization  or  utilization.  Rather,  the  individual 
subsystem  Functional  Area  Supervisors  conduct  training  on  an 
"as  needed"  basis  and  provide  basic  introductory  sessions 
with  newly- reported  personnel  who  will  be  using  that 
particular  subsystem. 

2 .  Command  Perception 

The  Commanding  Officer  had  been  in  command  for  18 
months  at  the  time  of  the  interview,  and  had  not  been  on 
board  during  the  initial  SNAP-II  hardware  installation  in  the 
shipyard.  His  personal  involvement  and  use  of  the  SNAP-II 
system  at  the  time  was  limited  to  using  the  MUSE  word  pro¬ 
cessing  subsystem  on  the  terminal  in  his  cabin.  Overall,  he 
regarded  the  system,  per  se,  as  a  very  capable  one  for  the 
functions  it  was  performing,  but  felt  that  it  could  be 
improved  in  several  respects.  His  basic  expectation  of  the 
personnel  using  the  system  was  not  in  the  form  of  increased 
output,  but  of  increased  efficiency  and  accuracy.  The  end 


result,  he  had  found,  was  that  people  were  not  more  efficient, 
but  were  merely  doing  business  in  another  way. 

In  contrast  to  the  Commanding  Officer,  the  Executive 
Officer  had  no  comments  to  make  about  the  SNAP- II  system. 
Although  he  had  a  terminal  in  his  stateroom,  he  did  not  make 
regular  use  of  the  system. 

The  Captain  had  a  limited  exposure  to  computer  systems 

through  various  academic  courses,  and  stated: 

.  .  .  I  know  what  a  computer  ought  to  do  for  me,  but  I  am 

not  a  computer  'buff'. 

The  major  issues  that  were  raised  during  the  inter¬ 
view  were  not  centered  on  specific  aspects  or  attributes  of 
the  SNAP-II  applications  and  systems  software  or  hardware, 
but  rather  on  broader  aspects,  such  as  documentation,  security, 
and  the  effect  of  SNAP-II  on  the  internal  management  of  the 
ship . 

a.  Security 

Regarding  the  issue  of  security  of  the  system, 
the  Captain  was  particularly  apprehensive  about  the  planned 
conversion  of  disbursing  records  to  the  Supply  and  Financial 
Subsystem  of  SNAP-II.  His  concern  was  that  records  would  be 
accessible  to  unauthorized  personnel,  even  though  the  system 
is  protected  by  a  system  of  individual  access  controls  to  the 
various  subsystems  through  use  of  passwords.  Concern  was 
expressed  about  the  manipulation  of  records,  not  the  actual 


theft  of  cash. 


In  the  Captain's  opinion,  any  system  with  a 


central  repository  of  records,  such  as  the  memory  disks  of 
the  SNAP- II  system,  was  susceptible  to  access  despite  any  and 
all  efforts  to  impose  administrative  controls.  What  was 
needed,  he  thought,  was  a  stand-alone  comput'er  where  the 
physical  control  of  the  disk  could  be  guaranteed- - i . e . ,  the 
disk  could  be  locked  up  when  not  in  use.  He  did  not  feel  that 
the  present  security  arrangements  of  the  SNAP- 1 1  system  were 
sufficient  to  guarantee  that  no  unauthorized  access  could 
take  place. 

b.  Documentation 

The  basic  question  raised  by  the  Commanding 

Officer  was,  who  was  the  system  documentation  aimed  at.  His 

perception  was  that  it  was  written  for  people  who  understood 

computers  to  start  with,  and  was  not  aimed  at  the  manager's 

viewpoint.  His  personal  experience  on  the  system  was  that  he 

was  learning  from  other  people,  not  from  the  documentation 

available.  Describing  the  current  documention  as  a  "cookbook" 

for  a  user,  he  did  not  feel  that  it  answered  the  basic 

questions  as  to  what  the  system  could  do  for  him  in  his 

position  as  the  Commanding  Officer  of  the  ship: 

How  can  the  Commanding  Officer  of  a  ship  with  'x'  number 
of  Department  Heads  use  it?  .  .  .  There  is  a  difference 

between  button  pushers  and  managers,  and  managers  don't 
understand  the  system  well  enough  to  know  what  the  system 
can  do  for  them. 

From  this  perspective,  the  Captain  felt  that  in 
addition  to  the  "pushbutton"  approach  to  documentation,  a 
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"level -by- level"  approach  was  required  so  that  different 
levels  of  system  users  would  be  given  different  views  and 
documentation  on  the  system.  By  the  " 1 evel - by  - 1 evel "  method, 
he  meant  that  Department  Heads,  Division  Officers,  and 
command- level  personnel  (CO/XO)  have'  different  needs  for 
different  kinds  of  information,  and  that  a  manual  describing 
the  system  from  those  reference  points  was  needed.  The  "cook¬ 
book"  approach  only  allowed  him  to  look  through  documentation 
to  find  specific  screens,  but  information  on  the  whole  issue 
of  CSMP  management  or  financial  reporting  for  instance,  was 
not  available. 

Summarizing,  he  felt  that  to  those  people  with 

a  limited  or  non-existent  knowledge  of  computers,  SNAP-II 

failed  miserably  in  its  documentation: 

I  MIGHT  be  able  to  get  a  hold  of  the  information  I  need, 
but  I  DEFY  anybody  to  go  into  the  documentation  and 
figure  it  out. 

c.  SNAP-II  and  Management 

The  SNAP-II  system  has  caused  the  Commanding 
Officer  to  question  the  applications  and  usefulness  of  the 
system  in  two  areas:  whether  it  was  a  useful  tool  from  a 
management  oversight  perspective,  and  whether  or  not  the 
impact  of  the  system  on  the  efficiency  of  mid-level  management 
(such  as  Department  Heads  and  Division  Officers)  was  a 
positive  one  or  not. 

Explaining  that  a  Commanding  Officer  had  different 
requirements  for  information  from  the  system  than  that  of 


others  in  the  chain-of-command,  the  Captain  felt  that  he 
could  not  obtain  information  of  an  analytical  or  aggregate 
nature  from  the  SNAP- 1 1  system.  What  was  needed,  he  felt, 
was  number  data  about  what  was  going  on  internally  in  his 
command- -how  many  requisitions  were  backlogged;  what  is  the 
spending  trend  of  the  ship?  A  particular  department?  A 
division? : 

Many  of  the  things  I  ask,  the  guy  has  got  to  go  back  to 
the  manual  thing  to  provide  the  answer. 

The  Captain  did  not  feel  that  the  system  was 

"management  friendly",  and  that  it  could  not  provide  the 

information  he  needed.  While  he  would  have  liked  many  things 

from  the  system,  he  did  find  that  at  the  lowest  levels,  that 

is,  the  level  of  people  who  had  to  use  the  system  to  carry 

out  their  everyday  jobs,  the  system  provided  neatness  and 

did  lead  to  increased  accuracy: 

If  it  was  not  intended  for  management  oversight,  its 
doing  its  job  .  .  .  from  a  managment  viewpoint,  I  am 

not  finding  it  useful. 

Regarding  the  net  effect  caused  by  the  intro¬ 
duction  of  the  SNAP- 1 1  system  on  the  efficiency  of  management 
in  his  command,  the  Captain  felt  that  there  were  basically 
two  effects--one  positive,  one  negat ive - - and  that  only  time 
and  experience  with  the  system  would  yield  a  clearcut  answer. 

The  negative  aspect  was  that  officers  were  forced 
to  sit  down  at  a  specific  location  (a  computer  terminal)  to 
review  and  approve/disapprove  supply  requisitions  or 


maintenance  action  documents.  The  biggest  problem  was 
getting  people  to  routinely  sit  down  at  a  terminal  and  review 
the  items  awaiting  their  action.  This  was  detrimental  in 
several  ways : 

-  The  officers  are  not  provided  with  their  own  terminals, 
and  must  use  terminals  that  are  in  use  by  the  data-entry 
personnel,  often  "bumping"  them.  This  delays  either  a 
user  or  an  approver,  and  the  work  at  hand  is  delayed. 

-  Officers  are  engaged  in  a  variety  of  tasks;  management  by 
walking  around  and  inspecting  is  common.  The  end  result 
is  that  an  officer  is  "out  and  about"  most  of  his  working 
day  (not  to  mention  watch  standing),  and  in  the  past, 
personnel  could  "walk  through"  important  paperwork  simply 
by  approaching  the  officer  anywhere  on  the  ship,  and  he 
could  approve/disapprove  the  item.  This  personal  contact 
afforded  the  time  and  place  for  pointed  questions  about 
what  was  going  on;  with  SNAP-II,  this  contact  is  lost 
and  action  might  be  delayed. 

On  the  positive  side,  the  Captain  pointed  out 
that  once  an  officer  approved  an  item,  it  was  instantly 
entered  into  the  system:  maintenance  actions  were  on  the  CSMP 
and  supply  requisitions  were  in  the  queue  for  Supply  Department 
action.  This  guaranteed  that  the  CSMP  was  instantly  updated 
and  correct  (a  rarity  in  the  past),  and  that  requisitions 
could  be  tracked  and  acted  on  with  precision.  The  internal 
efficiencies  of  this  were  difficult  to  measure  against  the 
external  inefficiencies  cited  previously. 

3 .  Middle  Level  Management  and  SNAP-II 

The  term  "middle  level  management"  applies  to  those 
officers  next  in  the  chain-of -command  under  the  Commanding 
and  Executive  Officers.  In  this  specific  case,  those 
interviewed  were  the  Operations  Officer,  the  Weapons  Officer, 


and  the  acting  Supply  Officer.  The  Chief  Engineer  was  not 


available.  All  are  ’’Department  Heads”,  in  charge  of  a  major 
administrative  group  within  the  ship. 

As  a  group,  these  managers  had  little  or  no  exposure 
to  computer's  or  computer  systems  prior  to  their  current 
situation.  The  only  formal  training  afforded  them  had  either 
been  conducted  on  board  by  NAVMASSO  DETPAC  during  the 
implementation  phase,  or  during  introductory  sessions  on 
SNAP-II  conducted  at  shore-side  schools  while  they  were 
enroute  to  the  fleet.  As  discussed  previously,  the  training 
during  the  implementation  phase  had  been  less  than  ideal 
because  of  the  shortage  of  terminals. 

In  contrast  with  the  Commanding  Officer,  who  viewed 
the  SNAP-II  system  from  a  broader  and  more  generalized 
perspective,  this  group  of  officers  viewed  the  system  with 
specific  items  in  mind  and  without  a  total  system  perspective. 
There  was  also  a  distinct  difference  in  perspective  and  use 
of  the  system  between  line  officers  and  the  Supply  Officer, 
perhaps  due  to  the  fact  that  the  Supply  Officer's  "bread  and 
butter”  is  tied  directly  to  the  SNAP-II  system--he  MUST  use 
it  to  perform  almost  all  aspects  of  his  job,  while  this  is 
not  true  of  the  line  Department  Heads, 
a.  Line  Management 

The  line  middle  level  managers  (Department  Heads) 
have  not  made  extensive  use  of  the  SNAP-II  system  beyond 
those  activities  for  which  there  is  no  alternative- -approving/ 
disapproving  supply  requisitions  and  maintenance  action 
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documents.  Word  processing  has  been  used,  but  not  extensively 
The  reasons  cited  for  this  were: 

-  lack  of  formal  training 

-  lack  of  time  for  training  after  arrival  on  board 

-  lack  of  terminal  availability  on  board 

However,  on  the  two  subsystems  that  had  to  be 
used  (MDS  and  SFM) ,  the  Department  Heads  were  pleased  with 
the  results  and  felt  that  their  personnel  were  more  accurate 
in  their  paperwork  and  tended  to  perform  paperwork  that  in 
the  past  had  not  always  been  accomplished,  such  as  deferred 
maintenance  actions  and  changes  to  equipment  configuration 
(CK's).  They  were  not  able  to  quantify  increased  productivity 
in  their  departments  as  a  result  of  the  SNAP- II  implementation 
There  was  mixed  response  to  the  question  of 
system  documentation  (user  manual)  adequacy,  ranging  from 
"good"  to  "poor".  In  general,  they  thought  that  their  people 
had  been  adequately  trained  to  use  the  system  for  the  basic 
functions  such  as  maintenance  action  reporting  and  generating 
requis it  ions . 

b.  The  Supply  Department 

Overall,  the  opinion  of  the  acting  Supply  Officer 
was  that  SNAP- 1 1  was  a  "great"  management  tool,  providing  for 
increased  accuracy  in  financial  reports  and  streamlining  the 
processing  of  supply  requisitions.  Not  all  of  the  SFM 
functions  were  being  utilized  to  one  degree  or  another;  for 
example,  the  SFOFDL  and  BOR  routines  had  not  been  employed 


lack  of  understanding 
time  consuming  to  use 

inability  to  change  output  (Budget  OPTAR  Report -- "BOR" ) 


(BOR  is  a  report  that  is  cumulative  in  nature  and  only  "seen" 
at  the  end  of  a  reporting  period--any  changes  or  corrections 
require  complete  reconstruction.) 

Duplication  was  also  occurring  in  several  areas 
due  to  problems  in  program  logic  and  lack  of  understanding 
and  trust  on  the  part  of  users  and  management.  For  example, 
the  internal  financial  budget  report  was  also  being  kept 
manually  because  requisitions  in  "queue"  to  the  Supply 
Department,  although  not  yet  approved  by  an  authorized  person, 
were  being  subtracted  from  the  ship's  budget,  causing  an 
erroneous  listing  of  the  current  budget  balance. 

It  was  not  felt  that  training  on  the  system  was 
a  problem  for  the  users- -the  Supply  Department  conducted 
their  own  training  for  the  users  and  considered  them 
adequately  knowledgeable  in  supply  procedures  to  be  able  to 
effectively  use  the  SNAP-II  system. 

In  summary,  the  acting  Supply  Officer  considered 
that  his  department  was  coping  very  well  with  the  SNAP-II 
system,  although  there  were  minor  problems  with  it  and  the 
system  was  not  being  employed  to  the  fullest  extent  possible. 
The  apparent  attitude  was  that  in  time,  as  people  gain  more 
experience  with  the  system  and  as  the  system  itself  becomes 
more  refined,  greater  use  would  be  made  of  it. 
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System  Operation  and  Maintenance 

The  Assistant  Supply  Officer  is  designated  as  the 


System  Coordinator,  with  a  Chief  Petty  Officer  from  the 
Supply  Department  as  the  Assistant  System  Coordinator.  The 
Assistant  Supply  Officer  is  also  the  Supply  and  Financial 
Management  subsystem  Functional  Area  Supervisor  (FAS) .  The 
other  Functional  Area  Supervisors  are  as  follows: 

-  MDS--3-M  Coordinator  (MMCM) 

-  ADM--Chief  Petty  Officer  (PNC) 

a.  Hardware 

Hardware  maintenance  is  performed  primarily  by  a 
Data  Systems  Technician  (DS  rating),  as  explained  previously, 
with  a  Postal  Clerk  (PC  rating)  as  his  assistant.  The 
training  received  by  the  maintainers  was  considered  adequate, 
as  is  the  technical  documentation  that  they  use  to  carry  out 
the  maintenance. 

As  the  duties  of  the  maintainers  are  collateral 
in  nature  vice  a  primary  duty,  the  maintainers  did  feel  that 
it  interfered  with  their  primary  duties,  although  the  amount 
of  interference  was  not  quantifiable  or  verifiable  with  the 
System  Coordinator.  The  scope  and  depth  of  the  preventive 
maintenance  performed  was  considered  to  be  adequate. 

b.  System  Coordinator  and  SMS  FAS 

The  System  Coordinator  rated  the  training  he 
received  from  NAVMASSO  DETPAC  as  good,  and  felt  that  he  could 
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provide  adequate  training  to  his  relief.  Managing  the  system 
with  a  group  of  people  on  a  collateral  duty  basis  was  not  a 
particular  problem.  As  the  System  Coordinator,  the  Assistant 
Supply  Officer  spent  about  an  hour  to  an  hour  and  a  half  each 
day  taking  care  of  routine  and  emergent  system- related  jobs, 
such  as  conducting  backups,  clearing  system  problems,  and 
routine  administration.  He  did  not  feel  that  this  detracted 
from  his  primary  duties,  but  he  did  feel  that  the  System 
Coordinator's  workload  would  increase  in  the  future  as  people 
became  more  familiar  with  the  system  and  made  more  extensive 
use  of  it. 

Maintenance  and  operation  of  system  hardware  was 
not  a  particular  problem,  and  it  was  felt  that  the  performance 
of  the  System  Management  Subsystem  (SMS)  was  good.  The 
support  provided  by  NAVMASSO  DETPAC  and  NAVSEACENPAC  was 
considered  to  be  very  good. 

As  the  System  Coordinator,  the  Assistant  Supply 
Officer  was  not  directly  involved  in  the  training  or  indoc¬ 
trination  of  new  users.  That  function  was  left  to  the 
individual  Functional  Area  Supervisors  and  the  departments 
concerned.  He  did  feel  that  the  initial  training  provided  by 
NAVMASSO  DETPAC  could  have  been  more  in-depth,  although  the 
lack  of  terminals  could  have  had  a  bearing  on  that. 

His  interactions  with  the  various  personnel 
associated  with  the  system,  from  the  CO/XO  down  to  the 
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everyday  user,  ranged  from  "not  much"  to  "little  or  none", 
respectively.  Most  of  the  system  administration  and  problem 
solving  was  delegated  to  the  Functional  Area  Supervisors, 
c.  Functional  Area  Supervisors 

(1)  SFM  FAS.  The  Functional  Area  Supervisor  for 
the  Supply  and  Financial  Management  module  is  the  Assistant 
Supply  Officer,  and  as  such,  his  views  will  not  be  repeated 
here  as  they  have  been  covered  previously  under  the  Supply 
Officer  section  and  the  System  Coordinator  section. 

(2)  MDS  FAS.  The  Functional  Area  Supervisor  for 
the  Maintenance  Data  Subsystem  is  the  ship's  3-M  Coordinator, 
a  Master  Chief  Machinist's  Mate  (MMCM) .  The  MDS  subsystem  is 
perhaps  unique  when  compared  with  the  other  subsystems  in 
that  every  work  center  on  the  ship  is  actively  involved  in 
data  entry  and  retrieval  from  it.  Because  of  this,  the  MDS 
FAS  is  concerned  with  input  quality  and  training  on  a 
ship-wide  basis. 

On  the  subject  of  training,  the  Master  Chief 
indicated  that  he  was  still  in  the  learning  process  and  that 
he  was  not  yet  completely  familiar  with  all  the  facets  and 
components  of  his  subsystem.  All  of  his  training  as  the  MDS 
FAS  had  come  from  the  person  he  had  relieved,  and,  although 
he  regarded  the  system  as  "simple”,  he  would  not  mind  having 
some  formal  schooling  on  the  SNAP- 1 1  system. 

As  far  as  training  personnel  who  use  the  MDS 
subsystem,  there  was  no  formalized  training  instituted. 


kather,  training  was  conducted  on  a  "one  on  one"  basis  for 
new  personnel  and  others,  as  required,  by  the  Master  Chief. 
Insofar  as  improvements  in  the  training  methodology,  the 
Master  Chief  felt  that  the  addition  of  some  form  of  "programmed 
instruction”  on  an  interactive  basis  on  the  computer  terminals 
would  be  helpful,  as  would  be  video-taped  programs  that  could 
be  played  over  the  ship's  closed  circuit  television  system. 

In  the  area  of  system  administration,  both 
internal  and  external  to  the  ship,  all  questions  or  suggestions 
were  forwarded  to  the  System  Coordinator  for  resolution.  As 
such  the  Master  Chief  reported  little  or  no  contact  was  made 
with  outside  activities  for  clarifying  procedures  or  to  make 
suggestions  for  system  improvements. 

Rating  the  documentation  for  his  subsystem  as 
adequate,  the  Master  Chief  felt  that  MDS  was  the  best  sub¬ 
system  within  SNAP-II,  and  that  he  and  the  personnel  actually 
using  the  subsystem  for  data  entry  were  pleased  with  the 
results  they  were  obtaining  from  the  system. 

(2)  ADM  FAS .  The  Administrative  Data  Management 
subsystem  (ADM)  FAS,  a  Chief  Petty  Officer  (PNC),  regarded 
the  system  as  a  time  saving  device  that  was  tailored  to  his 
needs.  He  reported  no  particular  problem  in  any  area  of  his 
subsystem,  and  was  completely  satisfied  with  what  he  was 
using.  He  had  no  recommendations  for  changes. 


C.  CASE  5 


1 .  Introduction 

One  of  the  first  ships  to  receive  SNAP- II,  this  East 
Coast  destroyer  (DD)  suffered  as  a  result  of  a  rushed  instal¬ 
lation  and  implementation  in  January  1985.  The  ship  received 
the  standard  SNAP-II  equipment  configuration  for  a  ship  of 
her  class  and  size  with  implementation  training  conducted  in 
January  1985  by  NAVMASSO.  The  SNAP-II  system  was  installed 
just  prior  to  deployment  and  the  training  was  conducted  during 
the  transit  overseas.  The  reason  for  the  rushed  installation 
was  not  known  to  current  ship’s  company.  As  a  result  of  the 
rushed  installation,  the  conversion  from  manual  to  mechanized 
records  was  less  than  optimal.  Problems  arose  as  the  result 
of  the  ship's  inaccurate  input  to  the  databases  (supply, 
maintenance,  and  administration)  and  from  hurried  processing 
and  inadequate  quality  assurance  on  part  of  the  contractor 
(SMA)  and  the  Navy  shore  establishment. 

The  implementation  training  received  from  NAVMASSO 
was  not  very  effective,  due  to  the  preoccupation  of  shipboard 
personnel  with  operational  and  deployment  evolutions.  The 
system  documentation  was  not  able  to  fill  the  gap  left  by  the 
inadequate  implementation  training. 

Figures  (1)  and  (2)  in  Chapter  II  delineate  the 
standard  organization  of  a  surface  combatant  after  imple¬ 
mentation  of  SNAP-II.  The  3-M  Coordinator  has  been 
designated  as  the  System  Coordinator,  with  an  Electronics 


Technician  First  Class  assigned  as  his  assistant.  Maintenance 
on  the  equipment  was  performed  by  Data  Systems  Technicians 
(DS) .  The  Functional  Area  Supervisors  were  assigned  in 
accordance  with  the  directive's  of  the  Type  Commander, 
Commander,  Naval  Surface  Forces,  U.S.  Atlantic  Fleet 
(COMNAVSURFLANT)  [Ref.  ll:p.  4]. 

The  ship  has  experienced  a  variety  of  problems  with 
the  software.  The  most  severe  software  problems  stemmed 
from  the  rushed  implementation  and  the  remainder  of  the 
software  problems  could  be  characterized  as  growing  pains. 

The  Supply  data  base  (inventory  stock  records),  maintenance 
data  base  (CSMP) ,  and  the  Administration  data  base  (personnel 
data)  all  suffered  integrity  problems.  The  source  of  the 
problems  could  not  be  directly  linked  to  any  specific  action 
but  the  end  result  was  a  lowering  of  the  creditability  of  the 
system  and  a  reluctance  on  the  part  of  the  users  to  utilize 
the  system.  This,  coupled  with  a  significant  amount  of 
downtime  (five  weeks)  caused  by  equipment  failure  (power 
supply  failed)  and  a  software  problem  (loading  updates) , 
resulted  in  slowing  down  the  process  of  bringing  the  system 
fully  in  line. 

The  ship's  personnel  have  finally  accepted  the  SNAP- 
II  system  and  have  put  forth  an  effort  to  utilize  it.  The 
SNAP-II  system  was  recognized  as  a  better  way  of  performing 
day-to-day  functions.  All  the  functions  were  not  yet  on  line 
but  the  ship  was  heading  in  that  direction.  The  functional 


area  programs  were  just  starting  to  be  utilized  for 
management  of  resources  beyond  what  was  required  by  the 
system.  As  an  overall  management  tool,  the  word  processing 
function  was  the  most  productively  utilized.  The  BASIC 
language  was  not  being  used  for  programming  due  to  lack  of 
programming  experience,  the  delayed  acceptance,  and  the  poor 
documentat ion . 

The  training  program  consists  of  on-the-job  training 
within  the  functional  areas  and  training  of  reliefs  by  the 
incumbent.  The  command  does  not  have  a  formal  training 
program  or  indoctrination  program  for  newly  transferred 
personnel.  The  ship  does  not  have  an  instruction  for  the  use 
and  management  of  the  SNAP- 1 1  system. 

2 .  Command  Perception 

The  Commanding  Officer  was  a  surface  line  Commander 
with  previous  experience  on  a  SNAP- 1 1  ship  as  the  Executive 
Officer.  He  was  not  on  board  during  the  installation  and 
implementation  on  this  ship.  The  Commanding  Officer  did  not 
personally  use  the  system,  but  a  growing  proportion  of  the 
administrative  workload  in  the  ship  was  being  produced  with 
the  system's  word  processing  function.  He  was  interested  in 
learning  to  use  the  system,  but  he  has  not  received  any- 
training,  and  competing  operational  priorities  override  his 
desire  to  learn.  The  training  by  N'AVMASSO  was  "implemented 


from  the  grass  roots  up  and  did  not  reach  his  level", 
felt  the  system  was  a  "good  thing  and  the  thing  of  the 


He 


future",  but  as  with  any  new  system,  it  has  its  share  of 
"growing  pains".  He  felt  his  personnel  were  using  the  system 
and  learning  to  use  it  effectively. 

The  Commanding  Officer  was  not  aware  of  the  management 
capabilities  that  the  system  afforded  and  did  not  view  it  as 
an  important  managment  tool  at  the  command  level.  Over  the 
next  several  years,  he  felt  Commanding  Officers  and  Executive 
Officers  would  experience  an  "education/training  gap"  in  the 
management  of  the  SNAP- II  system,  until  the  current  department 
heads  with  knowledge  of  SNAP-II  were  promoted  to  the  CO/XO 
level . 

The  Commanding  Officer  felt  he  should  not  have  to  be 
involved  in  the  management  of  the  SNAP-II  system  unless  there 
were  major  problems,  and  felt  that  the  system  did  not  need 
his  guidance  or  support  to  achieve  acceptable  performance. 

He  devotes  his  "time  to  trouble  spots  and  where  he  can  make 
the  most  money". 

3 .  Middle  Level  Management  and  SNAP-II 

The  middle  level  management,  for  the  purposes  of  this 
review  of  the  SNAP-II  system,  consists  of  the  Department 
Heads.  On  board  this  ship,  those  interviewed  included  the 
Combat  Systems  Officer,  the  Operations  Officer,  the 
Engineering  Officer  and  the  Supply  Officer.  The  Engineering 
Officer  was  the  only  officer  without  computer  training  or 
experience  prior  to  this  billet.  The  Combat  Systems  Officer 
(CSO)  and  the  Operations  Officer  (OPS)  had  taken  courses  in 


college,  and  the  Supply  Officer  had  prior  experience  with  the 
Navy's  Uniform  Automated  Data  Processing  System  (UADPS) .  Non 
of  these  officers  had  training  or  experience  with  the  SNAP- 1 1 
system  prior  to  their  current  billet. 

These  officers  viewed  the  SNAP-II  system  as  indis¬ 
pensable,  even  though  it  has  had  numerous  problems.  As  the 
Combat  Systems  Officer  stated,  "it  was  better  than  not  having 
it  on  board".  The  supply  and  maintenance  programs  were 
perceived  as  the  most  needed,  but  these  officers  were  most 
dependent  on  the  word  processing  function.  As  a  group,  they 
do  not  utilise  the  system  as  a  management  tool  for  planning 
reviewing  the  operation  of  their  administrative  functions. 

The  exception  to  this  was  the  Supply  Officer,  because  of  his 
being  more  dependent  on  the  SNAP-II  system  in  the  management 
of  his  department -- "As  SNAP-II  goes,  so  goes  the  Supply 
Department."  All  these  Department  Heads  use  the  system  to 
perform  routine  administrative  actions  within  their  functions 
(e.g.,  approving  NAVSUP  1250's  or  OI’NAV  4~90/2k's)  and  for 
word  processing.  Despite  the  absence  of  support  from  the 
Commanding  Officer  and  Executive  Officer,  they  regard  the 
system  as  capable  and  expect  it  to  help  improve  effectiveness 
and  accuracy.  As  the  Engineering  Department  Head  stated,  it 
was  a  "better  way  of  doing  the  same  thing." 

As  indicated  by  their  responses,  the  Department  Heads 
do  not  consider  the  SNAP-II  system  as  a  management  tool. 
Although  their  responses  to  the  interview  questions  consisted 


mainly  of  complaints  evolving  around  day-to-day  functioning 
of  the  programs,  the  following  management  issues  were  raised: 

-  Lack  of  adequate  documentation 

-  Lack  of  adequate  number  of  terminals 

-  Lack  of  communication 

-  Inadequate  knowledge  of  how  to  utilize  the  system  for 

management  of  their  functions 

-  Functional  area  management  problems 

a.  Lack  of  Adequate  Documentation 

The  middle  level  managers  found  the  documentation 
to  be  inadequate  for  training  new  users  and  of  only  limited 
use  in  answering  questions  or  solving  problems.  They  felt 
the  manuals  were  "written  for  computer  literate"  personnel  and 
not  for  the  novices  that  make  up  the  majority  of  the  users. 

None  of  the  officers  interviewed  used  the  documentation  because 
they  regarded  it  as  being  too  hard  to  understand  and  difficult 
to  use.  They  rely  on  their  personnel  to  have  the  requisite 
knowledge,  and  more  times  then  not  their  questions  go 
unanswered . 

The  documentation  did  not  provide  the  inter¬ 
relationships  of  the  various  data  bases  or  programs,  or  flow 
of  data  through  the  maintenance  and  supply  subystems.  A 
management  summary  that  could  provide  an  overview  of  the  system 
as  a  whole  was  cited  as  a  requirement  so  as  to  allow  the 
Department  Heads  to  effectively  utilize  the  system  to  manage 
their  departmental  functions. 

b.  Lack  of  Adequate  Number  of  Terminals 

The  middle  level  managers  felt  that  the  number  of 
terminals  needed  to  be  increased.  This  would  reduce  the  wasted 


man-hours  they  and  their  personnel  spend  searching  for  an  open 
terminal  or  waiting  in  line  to  use  one.  An  increase  in  terminals 
would  allow  more  work  to  be  accomplished  during  the  workday 
when  supervisors  were  present.  The  problem  was  partially 
caused  by  terminals  installed  in  limited  access  spaces,  in 
spaces  that  were  not  near  the  person's  work  area,  and  by 
inadequate  management  of  the  utilization  of  terminals.  They 
felt  that  the  main  reason  the  problem  existed  was  due  to  a 
lack  of  understanding  by  the  shore  establishment  of  the 
environment  the  afloat  personnel  operate  in.  A  significant 
number  of  documents  (supply  and  maintenance)  require  actions 
to  be  taken  at  other  than  the  time  the  officer  was  at  a 
terminal.  This  required  the  officer  to  stop  what  he  was  doing, 
hunt  down  a  terminal,  and  bump  someone  else  off  the  terminal 
or  stand  in  line.  The  alternative  was  to  put  the  document  on 
hold  or  to  create  a  walk  through  document,  both  of  which  have 
significant  repercussions. 

c.  Lack  of  Communication 

The  Department  Heads  felt  they  operated  in  a  void. 
They  had  little  or  no  knowledge  of  the  SNAP-II  program  as  it 
existed  outside  of  their  ship.  They  desired  to  see  more 
information  on  the  direction  the  SNAP-II  program  was  heading 
and  what  were  the  major  problems  the  system  was  experiencing. 

The  publications  that  did  exist  were  inadequate  in  their 
coverage  of  problems  being  experienced  by  other  users.  They 
wanted  to  see  the  solutions  to  problems  experienced  by  other 


users.  They  wanted  to  see  the  solutions  to  problems  experienced 
by  other  ships  or  something  to  indicate  that  action  was  being 
taken  on  problems,  and  if  there  were  any  interim  procedures 
that  could  be  employed. 

d.  Inadequate  Knowledge  to  Effectively  Utilize  the 

System  for  Management  of  Functions 

As  mentioned  previously,  there  was  no  system  over¬ 
view  or  management  guidelines  showing  how  to  utilize  the  system 
to  better  manage  their  functions.  The  Department  Head's  per¬ 
ception  was  that  no  thought  was  given  as  to  how  these  programs 
affect  the  management  of  a  department  or  how  the  computer  could 
be  used  to  improve  management  of  shipboard  resources.  The 
Supply  Officer  felt  the  computer  was  being  used  as  a  "transaction 
processing"  system  and  should  be  better  developed  as  a  management 
information  system.  They  had  to  grope  along  without  direction 
and  had  experienced  a  needless  waste  of  man-hours  to  gain  a 
workable  knowledge  of  their  role  as  users  and,  more  importantly, 
as  managers. 

e.  Functional  Area  Management  Problems 

The  Supply  Officer  felt  that  one  of  the  more 
difficult  problems  encountered  during  the  implementation  was 
the  lack  of  functional  area  knowledge  of  his  personnel.  He 
was  concerned  about  the  knowledge  of  the  personnel  he  received 
from  "A"  School  and  those  personnel  transferred  from  other 
commands.  The  storekeepers  had  to  be  taught  basic  storekeeping 
before  they  could  perform  functions  utilizing  SNAP-11  programs. 
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The  maintenance  personnel  had  the  same  problem  in  regard  to 
preparing  the  documentation  for  maintenance  actions. 

The  Supply  Officer  and  Engineering  Officer  noted 
that  they  had  been  hampered  by  the  lack  of  guidance  from  the 
functional  area  managers  (NAVSUP  and  NAVSEA) .  The  supply, 

3-M  and  maintenance  manuals  did  not  reflect  the  policy, 
guidance  or  procedures  to  be  utilized  by  shipboard  personnel 
in  processing  supply  and  maintenance  actions  with  the  SNAP- 1 1 
system . 

4 .  System  Operation  and  Maintenance 

The  3-M  Coordinator  was  designated  as  the  SNAP- 1 1 
System  Coordinator,  with  an  Electronic  Technician  First  Class 
as  the  Assistant  System  Coordinator.  The  Functional  Area 
Supervisors  were  as  follows: 

-  MDS--5-M  Coordinator  (EMC) 

-  SFM--Senior  Chief  Petty  Officer  (SKCS) 

-  ADM- -Chief  Petty  Officer  (YNC) 

Hardware  maintenance  was  performed  by  Data  System 
Technicians  (DS) .  The  documentation  and  training  they  received 
was  considered  adequate.  The  hardware  maintainers  were  con¬ 
cerned  about  this  function  taking  them  away  from  their  primary 
responsibilities,  but  they  have  had  no  significant  problems 
with  meeting  both  requirements.  The  preventive  maintenance 
was  considered  adequate. 

a.  System  Coordinator 

The  System  Coordinator  did  not  attend  the  NAVMASSO 
training  due  to  deployment  and  the  systems  manuals  did  not 


provide  him  with  the  basis  for  learning  the  responsibilities 
of  the  System  Coordinator.  He  felt  he  could  not  adequately 
train  a  replacement  and  felt  it  essential  that  his  relief  have 
both  the  5-M  and  System  Coordinator  school  prior  to  reporting 
on  board.  The  System  Coordinator  felt  that  utilizing  collatera 
duty  personnel  to  run  and  maintain  the  system  was  working  well. 

SNAP-II  Version  4.00.07  of  the  software  had 
recently  been  installed.  The  performance  of  System  Management 
Subsystem  (SMS)  was  considered  good,  with  the  support  received 
from  NAVMASSO  and  NAVSEACEN  considered  as  outstanding, 
b.  Functional  Area  Supervisors 

The  Functional  Area  Supervisors  shared  the  same 
concerns  as  the  middle  level  managers  about  training.  The 
primary  problems  in  the  training  area  were: 

-  poor  implementation  training 

-  lack  of  functional  knowledge 

-  no  formal  training  program  on  board 

The  documentation  was  rated  inadequate  for  training 
and  from  poor  to  acceptable  for  problem  solving/ inf ormat ion 
gathering.  They  felt  that  a  "cookbook  approach"  to  writing 
the  manuals  was  needed.  The  lack  of  guidance  from  Functional 
Area  Managers  (NAVSUP  and  NAVSEA)  was  cited  as  making  day-to- 
day  solving  of  problems  more  difficult. 

The  MDS  and  SFM  Functional  Area  Supervisors  felt 
their  programs  were  very  good.  They  reduced  errors  and  made 
the  processing  of  data  more  accurate  but  they  did  not  see  a 
reduction  in  man-hours  expended.  The  man-hours  were  shifted 


to  other  functions  or  consumed  by  performing  revised  procedures 
The  supervisors  were  divided  over  whether  SNAP- 1 1  increased 
productivity . 

The  ADM  supervisor  felt  the  program  was  not  a  time 
saver  for  either  the  yeomen  or  personnelmen ,  but  the  system 
produced  more  accurate  output  (shipboard  bills,  personal  data, 
career  counselor  information,  etc.)  and  the  output  was  easier 
to  update.  The  increase  in  accurate  output  was  offset  by 
increased  workload  due  to  an  increase  in  requests  for  outputs 
and  less  tolerance  for  inaccurate  or  untimely  output.  The  ADM 
supervisor  was  particularly  vehement  in  emphasizing  that  the 
system  was  too  slow  for  any  of  the  yeomen's  work  to  be 
performed  with  SNAP-II. 

D.  CASE  4 

1 .  Introduction 

The  SNAP-II  system  was  installed  on  board  this  Frigate 
(FF)  while  the  ship  was  nearing  the  completion  of  a  regularly 
scheduled  overhaul  (May  1984-January  1985).  Without  the  ship's 
foreknowledge,  COMNAVSURFPAC  and  NAVSEA  decided  to  accelerate 
the  ship's  SNAP-II  installation.  The  ship,  homeported  on  the 
West  Coast,  was  only  given  one  week's  notice  prior  to  the 
installation.  The  ship  received  the  standard  SNAP-II  hardware 
configuration  for  a  ship  of  her  class.  At  the  time  of  the 
interview,  version  4.00.07  of  the  software  was  being  installed. 
The  implementation  and  training  were  conducted  in  February  1985 


by  NAVMASSO  DETPAC.  The  records  conversion  and  loading  of 
databases  were  accomplished  without  significant  problems. 

Figures  (1)  and  (2)  in  Chapter  II  delineate  the  ship¬ 
board  organization  after  implementation  of  SNAP-II.  The  3-M 
Coordinator  had  been  designated  as  the  System  Coordinator, 
with  an  Electronics  Technician  Chief  Petty  Officer  assigned  as 
his  assistant.  Maintenance  on  the  equipment  was  performed  by 
Electronics  Technicians  (ET) .  The  Functional  Area  Supervisors 
were  assigned  in  accordance  with  the  directive's  of  the  Type 
Commander,  Commander  Naval  Surface  Forces,  Pacific  Fleet 
(COMNAVSURFPAC)  [Ref.  12:p.  4]. 

The  ship  had  experienced  only  minor  hardware  problems, 
and  had  one  Casualty  Report  (CASREP)  as  a  result  of  a  software 
failure,  in  which  the  system  locked  out  all  users.  The  casualty 
was  corrected  with  guidance  given  by  NAVMASSO  DETPAC  via  message 
traffic.  The  support  provided  by  NAVMASSO  DETPAC  and  NAVSEA 
NAVSEACENPAC  had  been  outstanding. 

The  SNAP-II  system  was  not  fully  implemented  on  board 
and  the  ship  had  experienced  a  significant  amount  of  "growing 
pains"  during  the  transition  process.  A  highlight  to  the 
process  was  the  ship's  effective  use  of  word  processing.  For 
this  ship,  the  word  processing  program  was  the  strongest 
mangagement  tool  in  the  SNAP-II  system.  The  ship's  personnel 
had  made  no  attempt  to  write  software  programs  using  the  BASIC 
language  provided  with  the  system.  This  was  due,  in  part,  to 
the  lack  of  adequate  documentation  and  training. 


The  ship  rated  the  SNAP- II  system  "very  good"  as  a 
Transaction  Processing  System.  They  were  impressed  with  the 
capability  of  the  supply  and  maintenance  functional  area  sub¬ 
systems.  Though  there  were  problems,  the  system  was  seen  as 
having  great  potential  and  was  highly  regarded  for  its  role  'in 
improving  accuracy  and  timeliness  of  data. 

The  training  program  consists  of  on-the-job  training 
within  the  functional  areas  and  training  of  reliefs  by  the 
incumbent.  The  command  does  not  have  a  formal  training  program 
or  indoctrination  program  for  newly  transferred  personnel  and 
ship  does  not  have  an  instruction  for  the  use  and  management 
of  the  SNAP- II  system. 

2 .  Command  Perception 

The  Commanding  Officer  had  been  in  command  for  16  months 
at  the  time  of  the  interview  and  had  been  on  board  during  the 
installation  and  implementation  of  the  system.  He  "likes  the 
idea  of  SNAP- II"  and  "likes  what  is  there,"  and  regarded  it  as 
particularly  useful  in  the  material  management  arena.  "The 
improvement  in  the  quality  of  the  Ship's  Force  Work  List  (SFWLJ 
and  Current  Ships  Maintenance  Project  (CSMP)  was  impressive." 
SNAP- II  had  "really  cut  down  on  the  delays"  in  preparation  of 
work  packages  resulting  in  "immensely  increased  validity."  The 
SFM  subsystem  had  "bugs  in  the  programs"  and  they  had  to 
"maintain  dual  systems."  The  SFM  subsystem  has  proved  its 
value  in  the  processing  of  routine  paperwork  and  creating 
reports.  In  the  personnel  urea,  "it  (SNAP-II)  would  be  useful, 


except  I  lack  (an  adequate  number  of)  personnel"  to  maintain 
the  data  base. 

Personnel  related  issues  dominated  the  interviews  but 

he  felt  they  were  "only  part  of  a  bigger  problem."  The 

Commanding  Officer  put  it  this  way: 

The  problem  is  that  a  ship  is  tasked  to  do  so  many  things 
but  the  number  of  people  never  change.  Now  I've  got  a  new 
computer  system  with  new  maintenance  and  administrative 
requirements.  I've  got  to  take  care  of  SNAP- II,  but  I 
didn't  receive  additional  personnel.  It's  typical  of  the 
way  we  do  business.  We  add,  add,  add...  Nobody  takes 
anything  away.  Then  CNO  or  SECNAV  come  out  with  an 
administration  reduction  program,  listing  pages  of  message 
reports  that  were  deleted,  but  ship's  were  not  making  those 
reports . 

The  Commanding  Officer  thought  SNAP- II  was  a  good 
system,  but  a  computer  system  is  made  up  of  more  than  hardware 
and  software.  The  Commanding  Officer,  summarizing  how  he  felt 
stated: 

Where  you  have  good  people,  SNAP-II  performs  good  because 
your  people  make  it  work.  Where  your  people  are  weak, 
SNAP-II  is  no  better  than  they  are. 

3 .  Middle  Level  Management  and  SNAP-II 

The  middle  level  management  consists  of  the  officers 
in  charge  of  departments.  Those  interviewed  were  the  Supply 
Officer,  the  Operations  Officer,  and  the  Engineering  Officer. 
The  Administrative  Officer,  although  not  a  department  head, 
was  also  interviewed.  The  Administrative  Officer  and  the 
Engineering  Officer  did  not  have  training  or  experience  in 
computer  operations  prior  to  their  current  billets.  The 
Operations  Officer  had  some  computer  courses  in  college  but 
did  not  have  practical  experience.  The  Supply  Officer  was  in 


one  of  the  first  groups  of  Supply  officers  to  receive  the 
SNAP- II  training  offered  at  Navy  Supply  Corps  School  for 
officers  going  to  sea  billets.  Also,  he  had  been  on  board  a 
destroyer  with  a  Wang  VS-80  minicomputer. 

The  Department  Heads  felt  the  system  did  not  have 
command  level  support.  This  hindered  the  ship  in  fully 
implementing  all  the  subsystems  and  had  reduced  the  drive  to 
"push  the  system  to  its  maximum." 

The  Department  Heads  had  high  expectations  of  the 
system,  and  SNAP- 1 1  more  than  lived  up  to  them.  The  system 
brings  a  welcomed  reduction  in  the  overburdening  process  of 
handling  paperwork.  As  the  Operations  Officer  stated,  "the 
system  was  needed  and  now  I  do  not  want  to  do  without  it." 

The  Department  Heads  discussed  the  "management  tools"  the 
system  provides  for  coping  with  the  day-to-day  workload.  The 
most  discussed  were  the  approval  processes  for  supply  material 
requests  and  work  requests,  and  a  variety  of  word  processing 
applications.  The  word  processing  was  the  only  program  that 
was  used  for  management  beyond  the  day-to-day  processing  of 
transactions  and  required  reports. 

a.  Training 

The  implementation  training  by  NAVMASSO  DETPAC 
thought  the  necessary  knowledge  to  the  ship  to  make  the  SNAP- 
II  system  operational.  However,  the  training  was  lacking 
from  the  management  perspective.  It  did  not  provide  the 
Department  Heads  with  the  necessary  instruments  to  manage 


their  functional  areas.  As  the  Engineering  Officer  remarked, 
"I  was  given  a  tool  and  no  instructions  on  how  to  use  it." 

The  Department  Heads  as  a  group  could  not  perceive  what  the 
system  could  do  for  them  as  managers,  beyond  mechanizing  the 
manual  procedures.  Having  attended'  SNAP- 1 1  training  and  due 
to  the  deep  personal  involvement  with  the  SFM  subsystem,  the 
Supply  Officer  did  have  a  clearer  understanding  of  the 
management  capabilities  of  SNAP- II.  This  made  it  clear  to 
him  that  the  system  was  not  "designed  with  the  management 
aspect  in  mind." 

The  Operations  Officer  and  the  Supply  Officer 
desired  to  see  off-ship  training  expanded  rapidly.  They  were 
most  concerned  about  having  training  for  officers,  Functional 
Area  Supervisors  and  the  System  Coordinator  prior  to  reporting 
on  board.  They  stressed  the  management  aspects  for  officers 
and  for  the  Functional  Area  Supervisors, 
b.  Dependency  on  the  System 

The  department  heads  expressed  concern  over  the 
dependency  on  the  SNAP- 1 1  system.  It  seemed  to  them  that  the 
shipboard  supply  and  maintenance,  and  to  a  lesser  extent  the 
administrative  system,  were  heading  toward  total  dependency 
on  SNAP- II.  The  Supply  Officer  did  not  feel  that  the  long¬ 
term  effect  of  SNAP-II  on  the  ship  had  been  adequately  studied 
He  was  concerned  about  the  effect  of  downtime  on  the  operation 
and  how  he  would  process  a  sizable  backlog  with  existing 
resources.  The  Operations  Officer  wanted  a  backup  capability 
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(redundancy)  in  the  equipment  to  avoid  the  possible  effects  of 
downt ime . 


c.  Lack  of  Adequate  Number  of  Terminals 

The  Department  Heads  were  troubled  by  the  problem 
of  access  to  terminals.  They  felt  that  too  much  time  was 
being  spent  trying  to  find  an  open  terminal  or  waiting  in  line 
to  use  terminals.  This  had  a  greater  affect  on  the  enlisted 
personnel  than  on  the  officers.  The  enlisted  personnel  mainly 
use  terminals  for  work  that  must  be  done.  The  officers  usage 
is  more  discretionary.  The  system  would  be  used  more  frequently 
by  officers  if  they  had  more  convenient  access  to  terminals. 
Though  the  Supply  and  Engineering  Officers  talked  of  using 
terminals  for  MDS  and  SFM  subsystem  management,  the  Department 
Heads  were  stressing  the  use  of  the  word  processing  function. 

The  suggestion  was  that  greater  benefit  may  be  obtained  from 
expanding  the  word  processing  capability  than  by  increasing 
the  management  information  and  decision  support  capabilities 
of  the  system. 

4.  System  Operation  and  Maintenance 


The  3-M  Coordinator  was  designated  as  the  SNAP- 1 1 
System  Coordinator,  with  an  Electronic  Technician  Chief  Petty 
Officer  as  the  Assistant  System  Coordinator.  The  Functional 
Area  Supervisors  were  as  follows: 

-  MDS- -3-M  Coordinator 

-  SFM--Senior  Chief  Petty  Officer  (SKCS) 

-  ADM--Chief  Petty  Officer  (YNC) 
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Hardware  maintenance  was  performed  by  Electronic 
Technicians  (ET) .  The  training  received  from  SMA  was  considered 
outstanding.  The  hardware  maintainers  felt  that  the  diagnostic 
tape  and  maintenance  manuals  were  very  good  and  spoke  highly 
of  the  system.  One  of  the  maintainers  commented,  "the  system 
is  very  reliable."  They  spoke  very  highly  of  the  support 
received  from  NAVSEACENPAC . 

a.  System  Coordinator 

The  System  Coordinator  rated  the  training  he 
received  from  NAVMASSO  DETPAC  as  adequate  but  too  limited  in 
scope  and  time  frame.  He  felt  he  needed  more  training  because 
of  his  lack  of  previous  computer  experience.  The  COMNAVSURFPAC 
directives  proved  helpful  in  grasping  the  full  extent  of  his 
responsibilities.  The  System  Coordinator  thought  that  his 
relief  had  to  have  training  prior  to  reporting  to  the  ship, 
and  that  the  Functional  Areas  needed  to  have  packaged  training 
for  use  on  board  the  ship.  The  implementation  training  the 
ship  received  from  NAVMASSO  DETPAC  was  rated  as  adequate,  and 
software  support  received  was  considered  "very  responsive". 

The  System  Coordinator  and  the  hardware  maintainers 


expressed  a  desire  to  have  the  policy  of  replacement  vice 
repair  modified.  They  had  had  problems  with  circuit  boards 
and  printers  that  they  felt  they  should  have  had  the  capability 
to  repair  on  board  but  had  to  be  shipped  to  a  central  repair 
facility.  The  ship  had  been  without  one  of  their  printers  for 
several  months  with  problems  that  they  probably  could  have 


corrected,  given  the  proper  tools  (repair  parts,  technical 
manuals,  training). 

b.  Functional  Area  Supervisors 

The  Functional  Area  Supervisors  shared  concerns 
about  training.  The  problems  cited  were: 

-  implementation  training  lacking  depth 

-  no  formal  training  program  on  board 

-  no  packaged  functional  area  training  for  supervisor 

-  personnel  lacked  adequate  functional  area  knowledge 

-  lack  of  off-ship  functional  area  training 

The  Functional  Area  Supervisors  felt  they  were 
impeded  by  the  lack  of  guidance  on  how  to  handle  problems. 
They  cited  the  Naval  Supply  Systems  manuals  and  the  3-M 
manuals  as  not  having  mechanized  procedures  or  guidance  on 
how  to  utilize  SNAP- II  within  those  functional  areas.  The 
Type  Commanders  have  provided  the  only  operational  guidance 
that  the  ship  had  recieved. 

The  Functional  Area  Supervisors  for  MDS  and  SFM 
were  very  positive  about  the  usefulness  and  the  ability  of 
subsystems  to  save  time.  The  MDS  subsystem  made  maintenance 
management  "so  much  easier  and  much  more  accurate”.  The  SFM 
Functional  Area  Supervisor  stated,  "the  system  is  good  but  it 
will  be  fantastic  when  the  bugs  arc  worked  out". 

E .  CASE  5 

1 .  Introduct ion 

This  Spruance - c 1  ass  destroyer,  homeported  in  Norfolk, 
Virginia,  commenced  installation  of  SNAP- 1 l  in  October  1983. 


By  Janaury  1984,  it  had  completed  installation  and  implemen¬ 
tation  of  the  system.  This  ship  has  the  standard  SNAP-II 
hardware  equipment  configuration  for  a  ship  of  her  class  and 
size.  Version  4.00.07  of  the  software  is  installed. 

The  initial  installation  of  the  hardware  by  SMA  and 
the  implementation  of  the  software  package  by  NAVMASSO  was 
completed  with  only  minor  problems.  The  conversion  of  stock 
records,  outstanding  requisitions,  CSMP,  and  COSAL  to  the  SNAP- 
II  system  contained  numerous  errors.  The  faults  were  later 
determined  not  to  have  resulted  from  the  conversion  process 
itself,  but  rather  as  a  result  of  incomplete  original  records. 
The  COSAL  is  still  not  complete. 

The  internal  SNAP-II  organization  is  structured  as 
delineated  in  Figures  (1)  and  (2)  in  Chapter  II.  However,  the 
ship  has  taken  a  different  approach  as  to  the  method  chosen 
to  manage  the  system.  The  Command  has  strong  beliefs  concerning 
the  importance  of  SNAP-II,  resulting  in  the  assignment  of  an 
officer  full-time  to  manage  the  SNAP-II  system.  The 
responsibilities  of  the  System  Coordinator  and  the  3-M 
Coordinator  have  been  assigned  to  one  individual,  referred  to 
as  the  "Maintenance  Officer".  As  the  XO's  direct  representative, 
he  is  responsible  for  the  complete  management  of  the  operational 
and  maintenance  aspects  of  SNAP-II.  The  remaining  Functional 
Area  Supervisors  are  assigned  in  accordance  with  the  Type 
Commanders  directive  [Ref.  11]. 


Initial  training  was  provided  to  the  Maintenance 
Officer  (System  Coordinator)  and  one  Hardware  Maintainer. 
Following  the  initial  training,  the  Maintenance  Officer  spent 
many  hours  on  the  system,  becoming  an  expert  in  all  its 
functions  and  operations.  He  personally  provides  continuous 
training  to  all  the  users  on  a  one-to-one  basis.  This  has 
increased  the  knowledge  level  of  the  crew,  but  has  not  been  a 
substitute  for  formal  organized  training. 

SNAP-II  is  in  the  forefront  of  the  day-to-day 
operations  on  board  this  ship.  Since  it  is  well  organized 
and  maintained,  a  high  level  of  confidence  is  held  in  the 
system.  The  dedication,  knowledge  of,  and  support  for  the 
system  provided  by  the  Maintenance  Officer  is  evident  and  is 
a  major  factor  behind  its  success. 

As  much  as  the  system  is  utilized,  the  various 
functions  are  not  completely  recognized  or  used.  A  perception 
that  the  system  is  overloaded,  coupled  with  the  lack  of  enough 
terminals  and  perceived  slow  response  time  are  the  causes  for 
this  situation.  Hardware  performance  had  been  very  good,  as 
has  been  the  support  received  from  NAVSEACENLANT  and  NAVMASSO. 

2 .  Command  Perception 

The  Command's  support  (CO/XO)  for  the  SNAP-II  can  be 
characterized  as  generally  positive.  However,  there  are  two 
distinct  pnilosophies  and  views  presented  by  these  individuals 
a.  Commanding  Officer 

The  Commanding  Officer,  having  considerable 
experience  in  Washington,  D.C.  (assigned  to  OP-05),  considers 


the  system  as  one  that  possibly  should  not  have  made  it  into 
the  fleet  in  its  present  configuration.  As  a  member  of  the 
OP-03  organization,  he  was  very  close  to  the  initial  con¬ 
ceptualization  and  program  start-up.  He  watched  the  procurement 
process  take  place  and  remembers  the  stages  of  development  as 
it  moved  through  the  various  political  and  military  process 
enroute  to  passing  its  Operational  Evaluation  and  Certification 
(OPEVAL)  and  finally  being  introduced  into  the  fleet.  His 
views  reflect  this  experience. 

The  Commanding  Officer  was  somewhat  reluctant  to 
press  his  support  beyond  the  general  acknowledgement  that  the 
system  exists  and  is  present  on  board  his  ship.  He  concentrated 
on  several  broad  topics  during  the  interview,  addressing 
neither  specific  hardware  nor  software  oriented  problems.  He 
personally  had  removed  himself  from  following  the  day-to-day 
operations  of  SNAP-II,  and  thus  did  not  feel  sufficiently 
knowledgeable  to  comment  on  hardware  or  software  related 
problems.  However,  he  did  comment  on  the  following  subjects: 

-  failure  of  program  management  to  recognize  inputs  from 

the  fleet 

-  personnel  dependency  on  the  system 

-  training 

( 1 )  Failure  of  Program  Management  to  Recognize 
Inputs  from  the  Fleet.  The  Commanding  Officer  felt  very 
strongly  that  the  system  was  built  without  really  considering 
what  he  called  "real  fleet  users  inputs.”  The  "real  fleet 


users"  were  defined  as  the  fleet  sailors,  Division  Officers, 
Department  Heads,  and  last,  but  not  least,  the  Commanding  and 


Executive  Officers.  He  acknowledged  that  there  was  a  study- 
conducted  in  the  form  of  questionnaires  that  had  solicited 
fleet  inputs,  but  he  questioned  the  use  of  the  results  from 
these  questionnaires.  He  felt  that  the  majority  of  the  issues 
addressed  in  the  questionnaire  were  not  included  in  the  design 
of  the  system: 

The  system  was  bought  by  people  who  were  not  going  to  be 
the  users  of  the  system.  They  were  management  types  up 
in  Washington  who  lived  in  data  processing  and  weren't  the 
types  who  were  going  to  sea  and  use  it.  They  obviously 
had  very  little  respect  for  fleet  inputs. 


(2)  Personnel  Dependency  on  the  System.  The  next 

character  of  the  system  discussed  was  the  one  which  the  CO 

referred  to  as  dependency.  He  felt  that  everyone  was  becoming 

too  dependent  on  the  system,  remarking  that  dependency  had 

turned  the  SNAP- II  system  into  a  huge  crutch: 

The  biggest  problem  I  see  out  here  is  that  it  has  become 
a  crutch.  If  I  want  an  answer  from  one  of  my  Department 
Heads  or  my  Division  Officers,  I  get  the  answer,  'well, 
SNAP's  down,  can't  get  that  to  you  right  now'.  They  rely 
on  that  machine  and  when  the  machine's  down,  you  can't  do 
it.  What  a  crutch. 


(3)  Training .  The  CO  voiced  his  opinion  that  plans 
for  formal  training  did  not  receive  appropriate  consideration 
and  attention  during  the  procurement  phase.  The  reason  for 
this,  he  felt,  could  be  tied  directly  to  the  method  by  which 
the  Navy  had  obtained  the  system.  He  believed  the  decision 
to  purchase  the  hardware  from  one  vendor  and  then  securing  a 
second  source  to  develop  software  broke  the  continuity  required 
to  formulate  a  good  training  plan,  one  that  would  accompany 
the  initial  implementation  of  the  system.  Under  these 


circumstances,  the  responsibility  for  development  of  a 


training  pi 
developer . 
retained  to 
a  drawn  out 


an  is  not  assumed  by  either  the  hardware  of  software 
Consequently,  a  third  party  normally  has  to  be 
develop  the  training  plan.  This  tends  to  become 
evolution,  as  witnessed  with  SNAP- II. 


We  should  have  gone  out  to  a  firm  like  IBM  and  said,  look, 
we  want  a  data  processing  system  to  meet  the  following 
requirements.  Let  them  produce  the  system  and  software. 
When  we  got  those,  we  would  have  had  an  in-depth  training 
program  accompanying  the  system.  Why  would  someone  put  a 
system  into  the  fleet  without  providing  the  proper  training 
necessary  to  support  it?  We  have  to  get  formal  training 
to  all  the  potential  users  before  reporting  on  board.  Not 
like  we  have  today. 


However  negative  the  comments  by  the  CO  appeared 


toward  the  system,  support  was  present.  Frustration  was  the 


dominant  underlying  factor  that  influenced  his  support  for  the 

system.  Asked,  ".  .  .  as  far  as  a  management  tool  for  you,  at 

the  Command  level,  is  it  providing  you  any  assistance?" 

No,  I'm  not  using  it.  I  don't  even  want  to  use  it.  I  don't 
call  it  up.  I  have  Admin  records  kept  on  SNAP,  which  I  ask 
to  have  delivered  to  me,  but  I  don't  touch  the  system. 


However,  he  continued: 

I  don't  discourage  anyone  from  using  it.  In  fact,  all  the 
8  O'clock  reports  and  all  this  stuff  comes  off  of  it.  I 
don't  hold  it  against  them  if  they  don't  use  it.  I  don't 
push  it.  I  don't  say  "why  don't  you  do  that  on  SNAP." 

I  hold  them  accountable  for  what  they’re  held  accountable 
for  as  a  Department  Head. 

b.  Executive  Officer 

On  the  other  hand,  the  Executive  Officer  expressed 
his  ideas  and  concerns  from  a  different  perspective.  His 
comments  reflect  the  many  hours  he  had  spent  in  direct  contac* 
with  individuals  connected  with  the  management  of  SNAP-1  I. 
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Unlike  the  CO,  the  XO  was  more  open  and  voiced  his  opinions 
in  numerous  areas  and  his  perception  of  the  system  as  a  useful 
shipboard  tool. 

(1)  Program  Support.  Although  not  a  heavy  user  of 
the  system  per  se,  he  considered  SXAP-II  to  be  "a  way  of  life" 
on  board  ships.  He  felt  that  the  support,  guidance  and 
considerations  afforded  the  system  from  external  support 
sources  had  to  drastically  change.  The  Executive  Officer  was 
concerned  that  the  system  is  not  understood  at  various  external 
commands,  those  which  are  responsible  for  supporting  the  system. 
He  felt  they  did  not  have  sufficient  insight  into  the  functions 
provided  by  the  system  and  how  they  should  be  incorporated 
into  the  shipboard  environment.  He  was  apprehensive  that 
these  same  individuals  did  not  fully  understand  the  impact 
the  system  had  on  the  way  ships  are  run  today: 

You  know,  everybody  thinks  it's  business  as  usual.  You 
just  have  a  little  computer  that  helps  you  with  your  job. 

The  Admin  of  a  ship  is  so  different  now.  I  don't  think  the 
Navy  has  realized  it,  but  the  way  you  administer  a  ship 
today  with  SNAP  on  it  is  completely  different. 

The  bottom  line  as  I  see  it,  the  Navy  just  has  to  accept 
the  fact  that  this  is  what's  going  to  happen  in  the  future 
and  everybody  has  got  to  get  on  board.  This  is  how  we're 
going  to  run  ships,  and  all  the  outside  activities  will 
just  have  to  accept  that  fact.  There  are  some  dinosaurs 
out  there  that  don't  want  to  do  that. 

Control,  as  defined  by  the  XO,  is  the  official 
establishment  of  a  central  point  of  contact  and  responsibility 
for  the  administrative  matters  pertaining  to  a  program.  He 
feels  control  has  not  been  defined  clearly  enough  to  the  fleet. 


A  defined  hierarchy  of  responsibility  could  not  be  ascertained. 

He  states  this  naturally  results  in  poor  standardization  which, 

in  turn,  affects  total  support  for  the  system. 

Part  of  the  problem  that  we  see  happening  with  SNAP  is  that 
the  Type  Commander  doesn't  realize  what  he  has  here.  We 
have  NAVMASSO,  we  got  RSG,  and  we  have  SURFLANT.  No  one 
has  taken  control  of  SNAP,  that's  what  we  see.  So 
consequently,  every  SNAP  ship  has  gone  off  on  its  own. 

Standardization  is  a  key  link  towards  the 

future  success  of  SNAP- II.  The  XO  expressed  a  desire  to  see 

some  standardized  guidelines  as  to  just  how  a  ship  is  supposed 

to  use  the  system.  He  did  not  expect  a  line  by  line  document 

as  to  the  nuts  and  bolts  of  operations,  but  something  that 

would  define  what  was  expected  from  the  system.  If  there  were 

defined  expectations,  then  maybe  the  external  support  units 

could  put  together  a  better  support  package: 

Now  that  we  have  a  system,  we  have  become  dependent  by 
virtue  of  its  functions.  There  still  is  no  control  over 
its  applications  and  really  just  how  it  is  to  be  used 
in  regards  to  how  it  is  expected  to  be  used.  I  think 
it  resides  at  the  Type  Commander.  He  needs  to  determine 
how  ships  are  going  to  be  organized  .  .  .  organize  and 
use  this  thing.  I’m  not  saying  he  has  to  give  us  some 
black  and  white  plan,  but  at  least  give  us  some  guidelines 
that  he  expects  us  to  follow.  The  Type  Commander  should 
come  out  and  say,  ok,  this  is  how  SNAP  ships  should  be 
set  up.  This  is  what  we  expect  the  ship  to  be  able  to  do. 

(2)  Training .  In  the  area  of  training,  the 
Executive  Officer  expressed  concern  that  at  the  user  level, 
there  appeared  to  be  little  action  planned  to  establish  some 
type  of  formal  training.  He  does  not  see  any  one  taking  control 
and  becoming  responsible  for  organizing  such  training. 


In  fact,  one  afternoon  I  called  down  to  NAVSURFLANT,  RSG, 
and  NAVMASSO  to  have  a  meeting  down  here.  They  really  got 
excited  because  I  looked  at  them  and  said,  "Ok,  who  is 
responsible  for  training?"  SURFLANT  would  look  at  RSG,  and 
RSG  would  look  at  NAVMASSO,  and  NAVMASSO  would  say,  "Wait 
a  minute.  I'm  just  an  implementer.  I  don't  do  anything 
like  that."  SURFLANT  would  say,  "RSG  is  our  agent  for 
training."  RSG  kind  of  looked  at  them  and  said,  "When  did 
that  happen?”  It's  simply  a  forest  out  there. 

The  Executive  Officer  commented  that  every 
supply  petty  officer  has  to  know  certain  things  about  SNAP- 1 1 
and  that  had  to  be  taught  to  him  somewhere,  definitely  prior 
to  arriving  on  board  a  ship.  The  idea  of  all  training  on  the 
system  taking  place  prior  to  an  individual  checking  on  board 
was  also  applicable  to  officers.  Once  an  officer  arrives  on 
board,  there  simply  isn't  enough  time  or  terminals  available 
for  him  to  sit  down  and  take  a  manual,  in  its  present  form, 
and  learn  SNAP- II: 

Training  simply  has  to  be  implemented  prior  to  arrival  to 
make  it  work. 

(3)  Other  Issues.  The  Executive  Officer  suggested 
numerous  other  improvements  as  well  as  venting  his  frustrations 
in  a  constructive  manner.  The  following  are  some  of  his 
comments  that  certainly  warrant  repeating: 

-  SNAP  needs  improvement  in  the  interface  with  the  shore 
maintenance  activities.  Still  passing  paper.  We  are 
still  required  to  use  work  packages,  run  AWR's  and  carry 
them  over. 

-  We  called  up  and  said,  "what  are  the  guidelines  for  how 
you  use  SNAP  within  the  supply  world?"  They  replied, 

"Well  its  in  Annex  W  of  our  SURFSUP!"  We  asked,  "Where 
is  Annex  W?"  They  said,  "Well,  the  draft  is  on  the  NT's 
desk."  We  have  had  SNAP- 1 1  for  two  years.  Doesn't  that 
sound  sad  to  you. 


-  One  of  this  ship's  major  problems  now  with  the  system  is 
the  lack  of  terminals.  Requirements  on  the  use  of  the 
system  have  overgrown  the  amount  of  terminals  that  it 
would  take  to  support. 

-  What's  going  to  happen  to  SNAP  when  a  ship  goes  into  the 
yard?  I  hope  someone  has  a  handle  on  this  one.  This 
ship  is  going  to  a  private  yard.  The  contractor  is  only 
required  to  provide  an  ADP  system.  The  ship  would  like 
to  see  another  SNAP  system  at  the  site  or  take  their 
system  off  to  shore.  Maybe  install  it  in  a  van! 

This  XO  continues  to  work  with  the  system  and 
supports  the  integration  of  SNAP- II  throughout  the  ship.  He 
states  that  he  feels  the  burden,  the  victories,  and  the  con¬ 
sequences  of  failure  of  SNAP- 1 1  more  than  anyone  else  on  board. 
He  summarized  his  feelings  about  the  system  as  follows: 

We  are  totally  dependent  on  the  damn  thing.  A  lot  of  people 
don't  realize  .  .  .  they  think  that  it's  just  a  computer 

that  helps  us  write  messages.  They  don't  realize  that  our 
whole  darn  supply  system  is  tied  up  in  it!  What  else  can 
I  say? 

3 .  Middle  Level  Management  and  SNAP- 1 1 

Middle  level  management,  as  defined  earlier,  are  those 
officers  in  the  chain  of  command  reporting  to  the  Commanding 
and  Executive  Officers.  In  the  case  of  this  ship,  the  fol¬ 
lowing  officers  were  interviewed:  the  Combat  Systems  Officer, 
the  Electronic  Material  Officer  (representing  the  Operations 
Officer),  and  the  Supply  Officer.  The  Engineering  Officer  was 
not  available. 

As  a  group,  these  individuals  had  little  experience 
working  with  computers.  The  Electronic  Material  Officer  (EMO) 
had  experience,  owning  a  home  computer  which  he  used 
extensively.  He  had  written  numerous  programs  and  was  active 
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in  a  local  computer  club.  On  the  other  hand,  the  Combat 
Systems  Officer  and  the  Supply  Officer  had  virtually  no  prior 
experience  with  computers.  They  acknowledged  that  computers 
had  only  existed  in  their  life  as  a  "work"  and  nothing  else. 

No  one  within  this  group  had  received  any  form  of 
training  on  the  system  before  reporting  on  board.  They  had 
only  been  introduced  to  the  system  through  the  implementation 
briefing  given  by  NAVMASSO.  Their  follow-on  training  had  been 
through  the  efforts  of  the  Maintenance  Officer.  At  Surface 
Warfare  Officer  School  (SWOS) ,  SNAP- I I  had  only  been  mentioned 
as  a  potential  system  that  they  might  encounter  in  the  fleet. 
No  other  explanation  or  in  depth  briefs  had  been  given. 

a.  Supply  Officer 

The  Supply  Officer  had  only  positive  remarks  about 
SNAP-II.  There  were  numerous  problems  associated  with  the 
conversion  of  stock  records,  outstanding  requisitions,  and 
CSMP  to  the  SNAP-II  system,  but  he  remained  confident  in  the 
system.  This  officer  felt  that  the  system  was  his  lifeli*e 
and  if  it  should  go  down  for  any  length  of  time,  he  would  "die 
a  quick  death". 

In  the  area  of  training,  he  felt  that  his 
personnel  were  not  adequately  trained  prior  to  their  arriving 
on  board.  Interesting  to  note,  he  endorsed  a  higher  GCT/ARI 
requirement  for  SK's  enroute  to  a  SNAP-II  equipped  ship, 
feeling  that  the  SNAP-II  system  required  a  higher  degree  of 

conceptualization  versus  the  former  "hands  on"  manual  method 
of  supply  procedures. 


b.  Combat  Systems  Officer 

The  CSO's  comments  and  views  generally  were 
addressed  to  SNAP's  use  as  a  word  processor  and  as  a  system 
to  handle  his  CSMP  and  supply  approval  process.  He  did  not 
see  it  as  a  management  tool.  His  training  so  far  had  only 
been  on  operating  the  system  to  review  documents  through  the 
menu  driven  mode.  He  has  not  found  the  time  nor  did  he  have 
the  desire  to  work  through  available  documentation  to  increase 
his  knowledge  of  the  system.  Having  to  continually  go  step-by- 
step  through  the  menu-driven  programs  without  an  option  to 
access  directly  the  function  he  wanted  seemed  to  him  to  be 
unnecessary.  Although  not  a  heavy  user  of  the  system  personally 
the  CSO  still  believed  that  if  the  system  were  to  go  down  for 
any  prolonged  period  of  time,  his  department  could  not  function. 

c.  Electronic  Material  Officer 

The  EMO  expressed  both  positive  support  for  the 

system  and  frustration  as  to  its  limited  capabilities.  As  an 

experienced  owner  and  user  of  a  home  computer,  his  use  of  the 

system  was  more  extensive  than  the  others.  He  personally  used 

the  system  to  adminster  his  CSMP,  produce  all  of  his  8  O'clock 

reports,  maintain  all  his  supp ly /ma intcnunce  transactions,  and 

made  extensive  use  of  the  MUSE  word  processing  application.  By 

EMO's  standards,  this  system  is  not  very  user  friendly.  He 

made  an  interesting  comment  with  regard  to  the  system  effecting 

his  daily  routine  as  a  manager: 

SNAP- I  I  is  controlling  my  work  instead  of  me  controlling 
it . 
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He  considers  the  system  too  slow  and  cumbersome  for  someone 
with  a  computer  background. 

4 .  System  Operation  and  Maintenance 
a.  System  Coordinator 

The  Maintenance  Officer  (a  Lieutenant)  performs 
the  functions  of  the  System  Coordinator,  3-M  Coordinator,  and 
is  the  MDS  Functional  Area  Supervisor.  He  is  assisted  by  a 
Senior  Chief  Petty  Officer  (EMCS) .  Their  role  functions  are 
the  control  of  maintenance  paperwork  and  the  operation  and 
maintenance  of  the  SNAP- 1 1  system.  The  Maintenance  Officer 
brought  out  the  following  key  issues: 

(1)  Training.  He  considered  his  initial  training 
by  NAVMASSO  as  oriented  toward  preparing  him  to  only  help 
someone  procedurally  through  their  particular  program.  Instead, 
he  felt  it  should  be  reoriented  to  provide  the  System  Coordinator 
with  an  understanding  of  the  entire  system.  He  remarked  that 

it  was  essential  that  the  System  Coordinator  have  a  good  know¬ 
ledge  of  all  the  functions  and  applications  and  how  they  fit 
together  to  work  as  a  system. 

Training  provided  for  the  Department  Heads  and 
Division  Officers  was  inadequate.  The  Department  Heads  and 
Division  Officers  do  not  use  the  system  as  a  management  tool 
due  to  the  simple  reason  that  they  have  not  been  trained  to 
use  it  as  such.  They  need  management  level  orientation. 

(2)  Documen  ta  t  ion .  Documentation  has  been  compiled 
and  written  somewhat  in  the  same  format  as  our  training  plans. 


It  is  partitioned  into  different  components  and  functions.  It 
does  not  bring  it  together  to  form  a  working  system.  This  is 
felt  to  be  adequate  for  someone  who  could  be  classified  as  a 
simple  button  pusher  but  not  for  someone  trying  to  understand 
the  system. 

(3)  Excessive  Duplication.  Excessive  duplication 
of  efforts  are  continuing  to  take  place.  The  requirements  for 
hard  copies  of  items  which  are  all  available  on  the  system  have 
not  decreased.  Shore  establishments  have  not  taken  the  effort 
to  get  on  board  with  the  fleet. 

In  closing,  the  Maintenance  Officer  offered 
the  following  comment: 

The  system  is  great  if  one  had  the  time  to  learn  it  all. 

I'm  trying  to  teach  everyone  as  much  as  possible  as  soon 
as  possible.  Time  may  solve  this  problem,  but  will  the 
system  survive  this  (training)  crisis?  It's  a  waste  not 
to  be  able  to  use  it  to  its  fullest  simply  because  someone 
has  dropped  the  ball  on  just  what  level  are  we  going  to 
train.  Someone  has  to  get  on  top  of  that  one  soon. 

Ignorance  will  kill  the  concept. 

b.  Functional  Area  Supervisors  (FAS) 

The  Functional  Area  Supervisor  for  MDS  was  the 
Maintenance  Officer.  His  comments  can  be  found  in  the  System 
Coordinator  section  and  will  not  be  repeated  here.  The  Supply 
Officer  and  a  PN1  were  assigned  as  the  Functional  Area 
Supervisors  for  SFM  and  ADM  subsystems,  respectively. 

As  a  group,  the  FAS's  all  expressed  total  support 
for  the  system.  They  each  felt  that  training  was  inadequate 


and  that  they  only  used  the  system  within  their  area  of 
responsibility.  They  all  agreed  that  the  job  could  be  handled 


in  a  satisfactory  manner  on  a  collateral  duty  basis.  Extensive 
comments  or  ideas  were  not  voiced  by  these  individuals.  "Yes" 
or  "very  much  so"  were  the  general  comments  when  questions 
were  asked. 

c.  Hardware  Maintainers 

The  hardware  is  presently  being  maintained  by  two 
Third  Class  DS's  assigned  from  the  Combat  Systems  department. 

The  training  provided  was  characterized  as  excellent.  Both 
individuals  felt  quite  confident  in  their  ability  to  maintain 
the  system.  As  a  collateral  duty  assignment,  they  felt  that 
they  did  have  sufficient  time  to  handle  the  additional 
requirements  for  scheduled  PMS  and  repairs.  Each  expressed 
excitement  about  their  association  with  the  equipment. 

The  only  negative  aspect  detected  came  in  the 
form  of  frustration  for  not  being  allowed  to  perform  maintenance 
in  a  n.ore  detailed  fashion.  They  expressed  concern  that  there 
were  numerous  conditions  that  arose  and  failures  that  occurred 
that  they  were  capable  of  fixing  if  the  maintenance  concept 
of  SNAP- 1 1  allowed  it . 

F.  CASE  6 

1 .  Introduct  ion 

The  completion  of  hardware  installation  in  this  East 
Coast  Spruance-class  destroyer  took  place  in  December,  1983. 

The  SNAP- I  I  System  was  fully  implemented  by  the  end  of 
Janaury,  1984.  This  ship  has  the  standard  SNAP- I  I  hardware 
equipment  configuration  for  a  ship  of  her  class  and  size. 


Version  4.00.07  of  the  SNAP-II  software  is  presently  installed 
and  operating  satisfactorily. 

The  installation  and  implementation  of  the  system  was 
successfully  completed  during  an  extended  in-port  period.  The 
success  of  this  was  attributed  to  the  excellent  implementation 
briefing  and  initial  training  provided  by  N'AVMASSO.  A 
contributing  factor  to  the  success  was  the  number  of  key 
individuals  on  board  that  had  exceptional  backgrounds  in 
information  systems.  All  difficulties  encountered  during  this 
period  were  promptly  resolved  by  NAVMASSO. 

The  system  has  functioned  satisfactorily  and  the 
support  received  from  NAVMASSO  and  NAVSEACEN  has  been  excellent 
While  on  an  extended  deployment  out  of  CONUS,  the  system 
experienced  a  power  supply  failure  and  through  extraordinary 
support  received  from  SMA  and  the  supply  system,  a  new  power 
supply  was  received  and  installed  in  less  than  82  hours. 

Support  for  the  system  throughout  the  entire  ship  is 
very  positive.  This  ship  had  been  a  prototype  installation 
for  the  SNAP-II  program,  designed  to  identify  what  requirements 
benefits  and  problems  would  be  associated  with  an  afloat 
automated  information  system.  As  a  result,  some  of  the 
per sonne 1  on  board  have  retained  a  personal  interest  in 
assuring  that  things  were  done  right  the  first  time. 

A  chief  petty  officer  (DSC),  very  experienced  in  the 


computer  field  and  have  a  B.S.  in  Computer  Science,  has  been 
assigned  as  the  System  Coordinator.  An  enthusiastic  First 


Class  Petty  Officer  (EMI)  is  assigned  as  his  assistant  as  well 
as  the  Functional  Area  Supervisor  for  the  MDS  subsystem.  A 
Chief  Petty  Officer  (SKC)  from  the  Supply  Department  and  a 
Chief  Petty  Officer  (PNC)  from  the  Personnel  Office  are  assigne 
as  the  Functional  Area  Supervisors  for  the  SFM  and  ADM  sub¬ 
systems,  respectively.  The  hardware  is  maintained  by  a  Second 
Class  Petty  Officer  (EW2)  and  a  Third  Class  Petty  Officer  (DS5) 
Both  of  these  petty  officers  are  from  the  Operations  Department 

Tremendous  attention  has  been  given  to  this  system  in 
order  to  assure  its  continuous  operation  and  support.  It  is 
used  virtually  by  all  levels  of  the  command.  Realizing  that 
the  system  is  supporting  the  entire  ship's  organization,  there 
was  a  display  of  enthusiasm  that  permeated  the  entire  ship. 

2 .  Command  Perception 

The  command  support  given  to  SNAP- 1 1  on  board  this  ship 
was  extremely  high.  Both  the  Commanding  Officer  and  his 
Executive  Officer  expressed  full  support  and  dedication  to  the 
system.  Although  the  Commanding  Officer  had  been  in  Command 
for  less  than  four  months  at  the  time  of  this  interview,  he 
was  quick  to  point  out  the  significance  and  the  benefits  of 
SNAP- II.  He  was  pleasantly  surprised  to  observe  the  intensity 
with  which  each  manager  used  the  system. 

The  Commanding  Officer  attributed  the  success  of  the 
system  to  the  intense  efforts  expended  by  the  System 
Coordinator.  He  felt  that  this  individual's  experience  and 


talent  had  paved  the  way  for  others  to  expand  their  knowledge 


and  use  of  the  system.  Having  an  experienced  System  Coordinator 
in  charge  of  the  system  gave  the  CO  a  feeling  of  enormous 
confidence  in  the  system. 

Generally,  the  Commanding  Officer  expressed  a  great 
degree  of  satisfaction  with  the  system.  Though  enthusiastic, 
he  was  not  sure  as  to  how  he  would  personally  use  SNAP-II,  if 
at  all.  He  had  a  terminal  in  his  cabin  but  had  not  used  it, 
nor  did  he  anticipate  using  it.  However,  theie  were  a  few 
areas  in  which  he  did  voice  concern. 

a.  Training 

In  the  area  of  training,  he  was  disappointed  in 
what  he  believed  to  be  the  failure  of  the  shore  establishment 
to  support  SNAP-II.  He  cited  a  case  of  sending  his  5-M 
Coordinator  to  school  and  finding  that  SNAP- 1 1  was  not  even 
mentioned.  He  was  frustrated  that  time  and  effort  had  been 
spent  to  send  this  individual  to  school  and  SNAP-II  was  not 
taught . 

b.  Standardization 

After  becoming  aware  that  there  were  some  minor 
problems  associated  with  the  system,  the  CO  attempted  to 
organize  a  cross  talk  program  with  other  ships  within  his 
squadron.  He  quickly  discovered  that  this  was  not  productive 
because  each  ship  had  implemented  SNAP-II  in  a  different 
manner.  There  was  no  standardization,  no  uniformity  in  depth 
and  breadth  of  system  use  and  application. 


The  Executive  Officer  reflected  the  majority  of 


the  comments  made  by  the  Commanding  Officer.  He  did  note  that 
SNAP-II  had  become  the  routine  way  of  doing  business  and  all 
activity  would  come  to  a  stop  if  the  ship  experienced  a 
casualty  to  the  system.  On  the  negative  side,  he  felt  that 
overall  support  from  the  shore  establishment  was  at  least  two 
to  four  years  behind  the  activities  of  the  fleet. 

5 .  Middle  Level  Managment  and  SNAP-II 

The  middle  level  managers  interviewed  were  the 
Operations  Officer,  Supply  Officer,  and  the  Engineering  Officer 
The  Combat  Systems  Officer  was  not  available  for  comment  at 
the  time  of  the  interview.  Within  this  group,  only  the 
Supply  Officer  had  any  previous  experience  working  with  any 
form  of  ADP.  He  had  been  in  numerous  billets  associated  with 
various  ADP  systems  and  had  been  assigned  as  the  SNAP-II 
Program  Officer  on  a  Type  Commander  staff.  The  remaining 
officers  had  been  exposed  to  the  SNAP-II  system  only  since 
reporting  on  board  this  ship. 

As  a  group,  these  officers  voiced  practically  the 
same  views  concerning  their  likes  and  dislikes  with  the  system. 
They  all  expressed  the  feeling  that  the  system  was  designed 
to  be  utilized  more  by  Division  Officers  and  assistants  than 
by  the  department  heads.  They  felt  the  system  did  not  provide 
the  information  they  needed  to  perform  their  jobs.  They  were 
not  heavy  users  of  the  system,  using  only  the  word  processing 
capabilities  and  the  functions  which  required  them  to  review 
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the  various  maintenance  and  supply  actions.  These  officers 
commented  that  their  enthusiasm  to  expand  their  use  of  the 
system  was  hampered  by  the  fact  that  they  had  not  received  any 
formal  training  on  the  system.  Each  one  commented  that  they 
did  not  have  the  time  to  devote  to  learning  the  system  once 
they  had  reported  on  board,  relying  instead  on  their  division 
officers  and  assistants  to  perform  subsystem  functions.  Each 
stated  that  they  were  comfortable  only  with  using  the  system 
as  a  word  processor  and  to  review  maintenance  and  supply 
actions.  Since  the  Department  Heads  had  not  developed  con¬ 
fidence  in  the  system,  they  continued  to  maintain  duplicate 
hard  copies  on  data  held  in  the  system. 

As  a  result  of  having  the  system  on  board,  each  middle 
manager  expressed  the  belief  that  he  certainly  expected  a  more 
complete  and  better  quality  product  from  his  subordinates. 

Since  it  was  relatively  easy  to  edit  their  input  and  correct 
mistakes,  error  free  documents  were  expected. 

4 .  System  Operation  and  Maintenance 

The  System  Coordinator  had  reported  on  board  without 
having  any  prior  experience  with  or  knowledge  of  SNAP- II.  He 
did,  however,  bring  with  him  12  years  of  experience  from 
working  closely  with  computers  in  the  Naval  Tactical  Data 

i 

System  (NTDS) ,  as  well  as  a  B.S.  in  Computer  Science.  He  has 
attended  the  System  Coordinator  course  conducted  by  NAVMASSO 
prior  to  implementation  of  the  system. 
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The  System  Coordinator  voiced  his  assessment  of  the 
system  in  broad  terms,  commenting  on  the  following  topics: 
installation/ implementation,  support  evaluation,  training,  and 
general  overall  software  evaluation. 

a.  Installation/ implementat ion 

During  the  installation  and  implementation  phase, 
the  ship  received  excellent  briefings  on  what  was  going  to  be 
installed  and  how  it  was  going  to  take  place.  At  no  time  was 
the  ship  asked  to  comment  on  what  was  going  to  happen  to  their 
ship.  "Here  is  what  you  are  going  to  get,  this  is  how  we  are 
going  to  install  it,  and  this  is  where  the  components  are 
going  to  be  placed"  was  the  order  of  the  day.  The  System 
Coordinator  felt  very  strongly  that  the  ships  should  have  the 
flexibility  in  determining  where  the  terminals  should  be 
installed . 

b.  Support  Evaluation 

The  support  and  attention  provided  to  the  system 
by  NAVMASSO  and  the  Type  Commander  was  considered  to  be 
outstanding.  When  there  were  problems  with  the  software, 
NAVMASSO  responded  almost  immediately.  The  response  to 
CASREPS  was  excellent,  and  software  problems  were  resolved 
through  message  traffic  in  an  expeditious  manner  while  the 
ship  was  deployed. 

c.  Training 

Training  was  considered  to  be  inadequate  at  all 
levels.  However,  he  did  think  that  a  considerable  amount  of 


training  could  be  accomplished  on  board  our  ships  if  there  was 
a  Navy-wide  plan  that  would  standardize  the  overall  training. 
The  System  Coordinator  felt  that  instituting  a  PQS  program 
would  go  a  long  way  in  achieving  that  goal.  Although  the 
System  Coordinator  was  orienting  his  comments  concerning 
training  toward  the  enlisted  personnel,  he  felt  strongly  that 
there  should  also  be  a  formal  training  plan  established  to 
provide  the  Department  Heads  and  Division  Officers  a  management 
oriented  approach  to  the  system. 

d.  Software  Evaluation 

The  software  as  presently  designed  was  considered 
adequate  for  a  user  that  has  to  take  a  step  by  step  approach 
to  any  application.  As  the  experience  level  of  individual 
using  the  system  increases,  this  approach  will  become  time 
consuming  and  will  be  considered  elementary,  creating  a  feeling 
among  users  that  the  system  is  becoming  obsolete  and  decreasing 
in  its  value  as  a  useful  information  system.  It  will  then 
become  annoying  to  work  with  the  system  as  it  is  presently 
designed,  thus  relegating  it  to  transaction  processing  only. 

In  summary,  the  System  Coordinator  is  a  very 

enthusiastic  individual  who  feels  that  the  system  is  the  way 

of  life  today  on  board  his  ship.  His  final  comment  was: 

The  system  is  an  excellent  one,  but  first  we  all  have  to 
learn  how  to  use  it  before  it  will  become  acceptable. 

The  Functional  Area  Supervisors  had  very  little  to 
say  about  the  system.  They  all  supported  the  system  and 


expressed  that  it  had  received  positive  support  throughout 
the  entire  command.  Since  the  System  Coordinator  took  it 
upon  himself  to  perform  essentially  all  the  duties  that  were 
normally  assigned  to  the  Functional  Area  Supervisors,  they 
remained  somewhat  aloof  and  accepted  this  status  quo. 


SUMMARY  OF  CASE  STUDIES 


The  previous  chapter  presented  the  views  of  shipboard 
personnel  who  have  been  operating  with  the  SNAP- 1 1  system  for 
at  least  one  year.  Their  perspectives  and  opinions  have  been 
developed  through  constant  association  and  experience  with 
the  system. 

The  following  summaries  present  a  synopsis  of  the  main 
issues  identified  by  the  individual  ships  as  having  had  an 
impact  on  the  integration  and  use  of  the  SNAP- 1 1  system 
within  their  organizations.  Also  included  are  summary 
evaluations  by  the  authors  as  to  the  general  extent  to  which 
the  SNAP-II  system  have  been  assimilated  by  the  ships,  based 
on  the  interviews  and  through  observation. 


A.  CASE  1 

1 .  Evaluation  of  Ship 

Stated  briefly,  this  ship  has  transitioned  successfully 
to  the  SNAP-II  system  and  personnel  are  finding  new  and  in¬ 
novative  ways  of  adapting  it  to  their  organization.  Users  at 
all  levels  of  the  ship  are  very  pleased  with  the  system  and 


are  using  it  extensively. 

Management  is  using  the  system  as  a  tool  rather  than 


relegating  it  to  use  at  the  lower  echelons  as  a  data  entry 
and  transaction  processing  system. 


The  ship  is  pleased  with  the  performance  of  the  hard¬ 


ware,  and  had  not  encountered  major  problems  in  the  concept 
of  using  collateral  duty  personnel  to  manage  and  maintain  the 
system.  Support  provided  by  NAVSEA  and  N'AVMASSO  was  regarded 
as  very  good. 

Evident  through  observation  and  as  a  result  of  the 
various  interviews,  the  ship  had  several  strong  qualities  that 
positively  influenced  the  implementation  of  the  SNAP- II 
system: 

-  a  strong  commitment  to  excellence  in  the  first  place 

-  personnel  with  backgrounds  in  computer  systems  available 

to  help  guide  the  transition 

-  strong  involvement  of  the  middle  level  managers  in  the 

transit  ion 

2 .  Significant  Issues 

The  specific  items  of  concern  raised  by  the  ship's 
personnel  and  regarded  as  significant  were  as  follows: 

-  Inadequate  documentation  for  the  various  levels  of  system 
users.  This  was  raised  from  several  perspectives, 
including  lack  of  readability  and  the  absence  of  different 
perspectives  and  levels  of  documentation  (i.e.  not  every¬ 
one  can  effectively  use  a  data-entry  user's  "view"  of  the 
system  to  understand  and  use  the  system)  . 

-  Training  was  brought  up  as  a  problem,  not  in  the  area  of 
initial  training,  but  in  the  context  of  "continuing 
education"  for  on  board  users  in  the  future,  and  from 
the  viewpoint  that  formal  schooling  should  be  made 
available  to  the  Functional  Area  Supervisors  (and  possibly 
lower  level  users)  in  addition  to  training  presently 
available  for  the  System  Coordinator. 

Although  not  specifically  alluded  to  during  the 
interviews,  there  were  two  further  areas  of  interest  evident: 

-  After  implementation  of  the  SNAP- 1 1  system,  the  ship  was 
not  reviewed  or  audited  by  program  management  to  find  out 


how  the  system  was  working.  There  was  no  positive  action 
to  find  out  if  there  were  problems  integrating  the  system, 
only  reaction  to  specific  problems  reported  by  the  ship. 

-  There  is  a  lack  of  understanding  of  how  the  program  is 
set  up  and  managed  ashore.  Because  of  NAVMASSO's  close 
involvement  in  the  conversion  and  implementation  of  the 
system,  the  ship  regards  them  as  the  focal  point  for 
dealing  with  SNAP- 1 1  problems  and  suggestions.  In  some 
cases  this  is  true.  Otherwise,  there  is  little  official 
communication  on  project  status,  improvements,  or  how 
the  project  is  being  handled  on  a  Navy-wide  basis. 


B.  CASE  2 

1 .  Evaluation  of  Ship 

Implementation  of  the  SNAP-II  system  in  this  ship  has 
been  successful  at  the  lower  levels  (data  entry  personnel), 
but  has  not  been  put  to  great  use  by  the  middle  level  managers. 
At  this  level,  it  appears  that  the  system  is  regarded  as 
something  to  be  contended  with,  and  as  such  is  not  used  as  a 
management  tool . 

While  the  system  is  appreciated  and  fully  backed  by 
the  command,  and  the  data  entry  personnel  are  having  no  problem 
using  the  system,  there  is  a  "gulf",  or  void  in  the  middle 
where  the  system  is  accepted  at  face  value  only.  There  is 
apparently  a  lack  of  understanding  as  to  how  to  incorporate 
the  system  so  as  to  derive  its  benefits. 

The  reason  for  the  above  is  not  a  lack  of  positive 
atmosphere  in  the  command.  The  benefits  derived  from  the 
system  arc  fully  appreciated  throughout  the  ship,  but  there 
has  been  no  movement  to  expand  the  use  of  the  system  or 
develop  new  methods  to  incorporate  it  as  a  management  tool. 


The  reasons  for  the  above  appear  to  be: 


-  lack  of  adequate  training  or  "selling  of  the  product"  to 

the  middle  level  managers 

-  the  documentation  is  regarded  as  difficult  to  assimilate 

-  system  capabilities  are  not  fully  understood  by  system 

management  personnel -- the  system  coordinator  and  the 
functional  area  supervisors 

The  ship  has  had  few  problems  with  the  hardware,  and 

support  of  the  system  by  NAVSEA  and  NAVMASSO  has  been  good. 

2 .  Significant  Issues 


Specific  items  of  concern  raised  by  shipboard  personnel 
include  the  following: 

-  documentation  not  aimed  at  management  and  difficult  to 

understand 

-  inability  to  derive  useful  information  that  can  be 

utilized  by  management 

-  the  effect  on  management  style  by  the  introduction  of  an 

automated  information  system 

-  the  adequacy  of  the  number  of  terminals  on  board 

An  additional  point  made  by  the  Commanding  Officer  was 
that  until  this  survey  had  been  conducted,  no  one  external  to 
the  ship  had  come  aboard  to  inquire  about  the  status  of  the 
system  and  how  the  ship  was  using  it. 


C .  CASE  5 

1 .  Evaluation  of  Ship 

The  hurried  manner  in  which  SNAP- 1  I  was  installed 
and  implemented  had  a  lasting  effect  on  the  performance  of 
this  ship.  Compounded  by  significant  downtime  shortly  after 
implementation,  the  personnel  lost  confidence  in  the  system 
resulting  in  a  slower  rate  of  progress  in  bringing  the  system 
on  line.  The  neutral  command  support  adversely  affected  the 


drive  of  the  personnel  to  utilize  the  system  and  has  resulted 
in  the  ship  still  not  performing  all  subsystem  functions. 


The  ship's  personnel  are  gaining  confidence  in  the 
system  and  have  started  to  effectively  use  the  system  for 
management  of  daily  operations.  The  middle  level  managers 
still  do  not  have  a  management  perspective  on  how  to  utilize 
SNAP- II.  They  perform  those  functions  that  are  mandatory  but 
do  not  seek  to  understand  the  potential  of  the  system  in 
assisting  them  in  managing  their  functions. 

Ship's  personnel  are  impressed  by  the  system's 
capability  to  perform  routine  work  and  think  that  despite 
its  shortcom ings ,  it  has  reduced  the  administrative  burden. 

As  the  Combat  Systems  Officer  stated,  it's  "better  than  not 
having  it  on  board." 

2 .  Significant  Issues 

The  interviews  with  ship's  personnel  uncovered  a 
myriad  of  problems,  suggestions  and  complaints.  The  followin 
issues  surfaced  as  being  the  most  significant: 

a.  SNAP- 1 1  needs  to  be  more  fully  developed  as  a 
management  information  system  and  the  ship's  command  and 
middle  level  managers  need  to  be  trained  in  the  effective  use 
of  the  system  as  a  management  tool. 

b.  The  shipboard  and  shore  establishment  personnel 


need  to  broaden  their  perspectives  on  the  effect  SNAP-II  has 
on  shipboard  routines.  It  is  currently  being  thought  of  as 
an  aid  to  management.  It  will  become  the  "management  system. 


Administratively  speaking,  the  ship  will  succeed  or  fail  by 
how  they  utilize  SNAP- II. 

c.  The  lack  of  access  to  terminals  hinders  effective 
use  of  the  SNAP- 1 1  system  and  wastes  precious  manhours. 

d.  Documentation  and  guidance  manuals  need  to  be 
improved  or  reflect  guidance  for  managing  with  the  SNAP- 1 1 
system.  Documentation  is  inadequate  for  training  new  users 
and  of  limited  value  in  solving  problems.  Guidance  in  using 
NAP- II  from  the  Functional  Managers  (e.g.,  NAVSUP  Manual  P-485 
OPNAV  5-M  Manuals)  is  nonexistent. 

D.  CASE  4 

1 .  Evaluation  of  Ship 

This  ship's  approach  to  management  is  to  manage  by 
exception  and  do  only  what  has  to  be  done.  In  one  word, 
"survive".  The  command  does  not  foster  the  use  of  SNAP-II. 

The  lackadaisical  approach  to  the  effective  utilization  of 
the  capabilities  of  the  system  leaves  subordinates  with  little 
enthusiasm  to  make  the  system  perform  effectively.  Currently, 
the  system  is  not  fully  implemented  and  various  functions  are 
not  utilized. 

The  ship  views  SNAP- I  1  as  merely  a  transaction  pro¬ 
cessing  system  and  SNAP- II  is  not  utilized  to  better  manage 
their  functions.  The  ship  has  just  replaced  a  manual  system 
with  a  mechanized  system  without  reaping  t  h  •  belief  its  of 
automation.  They  do  feel  it  has  great U  improved  the  accuracy 


and  timeliness  of  data  and  has  proved  its  value  to  the  ship. 
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Significant  Issues 

The  following  issues  came  to  the  forefront: 


a.  SXAP-II  system's  management  capabilities  need  to 
be  expanded  and  the  ship's  managers  need  training  in  how  to 
effectively  utilize  these  management  capabilities. 

b.  Training  needs  to  be  improved  in  the  following 

areas : 

-  depth  of  implementation  training 

-  packaged  training  for  Functional  Area  Supervisors  (FAS) 

-  Off-ship  training  needed  for  CO/XO  down  to  the  FAS  level 

-  functional  area  (rate)  training  needs  to  be  strengthened 

c.  The  number  of  terminals  need  to  be  increased  to 
reduce  man-hours  expended  waiting  for  terminals  and  to  expand 
access  for  management  uses. 

E.  CASE  5 

1 .  Evaluation  of  Ship 

The  installation  and  implementation  of  SNAP- 1 1  was 
conducted  in  an  orderly  and  expeditious  manner,  however,  the 
conversion  of  stock  records,  outstanding  requisition  file, 
CSMP,  and  COSAL  experienced  considerable  difficulties.  It 
could  not  be  determined  if  the  discrepancies  resulted  from 
the  conversion  process  or  were  present  in  the  original  record 
prior  to  conversion. 

The  Command  demonstrated  a  positive  attitude  toward 
the  system.  There  were  some  perception  differences  between 
the  Commanding  Officer  and  the  Executive  Officer;  the  CO  was 
frustrated  due  to  the  way  he  perceived  the  procurement  proces 


to  have  taken  place,  feeling  that  it  had  resulted  in  a  system 


designed  without  including  input  from  fleet  users.  This  had 
resulted  in  a  system  that  was  introduced  without  providing  an 
accompanying  Navy  Training  Plan.  The  Commanding  Officer  does 
support  the  system  and  desires  to  see  it  improved  to  a  point 
that  it  can  become  what  he  considers  a  management  tool.  On 
the  other  hand,  the  Executive  Officer  sees  it  as  the  way  the 
Navy  has  chosen  to  institute  on  board  automated  information 
systems.  Therefore  he  continually  strives  to  make  it  work. 

Unlike  other  ships  interviewed,  the  Command  chose  to 
take  a  different  approach  as  to  the  management  of  the  system. 

It  was  felt  that  the  importance  of  the  system  justified  the 
assignment  of  an  officer  full  time  to  manage  the  operations, 
maintenance  and  training  for  the  SNAP- II. 

The  middle  managers  were  all  supportive  of  the  system 
and  welcomed  its  contribution  in  relieving  their  administrative 
burdens.  They  all  voiced  their  opinions  that  if  they  had 
received  formal  training,  they  would  be  making  better  use  of 
the  system. 

2 .  Significant  Issues 

The  following  issues  surfaced  as  being  the  most 


significant: 


-  training  is  not  available  for  personnel  prior  to  reporting 
on  board,  lacks  a  management  perspective,  and  there  is  no 
action  on  implementing  the  Navy  Training  Plan 

-  inadequate  number  of  terminals 

-  lack  of  program  support  in  the  form  of  program  guidance, 
standardization  on  board  ships,  interface  with  external 
commands,  and  knowledge  of  impact  of  SNAP- 1 1  on  ship 


-  developing  the  system  as  a  Management  Information  System 

-  documentat ion  lacks  a  management  perspective 

F.  CASE  6 

1 .  Evaluation  of  Ship 

This  ship  enjoyed  a  successful  installation  and 
implementation  of  the  SNAP- 1 1  system.  The  hardware  and  peri¬ 
pherals  have  performed  satisfactorily,  creating  respect  and 
confidence  in  the  ability  of  the  system  to  perform  required 
functions.  The  only  comments  concerning  hardware  were  in  the 
form  of  requesting  more  terminals. 

The  system  is  operating  as  a  very  successful  transaction 
processing  system.  There  is  a  considerable  amount  of  computer 
knowledge  available  among  several  key  individuals.  This  no 
doubt  has  contributed  favorably  to  the  success  of  the  initial 
transition  as  well  as  the  continuous  operations  of  the  system. 

At  the  Command  level,  there  was  a  very  positive  attitude  toward 
the  overall  system  and  one  sensed  a  feeling  of  dedication 
toward  the  future  success  of  SNAP- II.  They  see  a  great  amount 
of  effort  going  into  the  system  and  in  turn  see  the  benefits 
it  returns.  Overall,  management  has  commented  that  the  SNAP- 1 1 
system  had  been  accepted  as  the  way  of  the  future  for  the  Navy 
in  regards  to  ADP  on  board  ships.  It  is  performing  adequately, 
but  no  one  really  knows  where  they  are  going  with  it. 

The  use  of  the  system  has  not  reached  its  full  potential. 
The  middle  level  managers  commented  that  they  were  not 

expanding  their  use  of  the  system  to  the  point  whereby  it  would 
become  useful  as  a  mangement  tool  because  they: 
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-  had  not  been  afforded  the  necessary  training  prior  to 
arriving  on  board  to  effectively  use  the  system  as  a 
management  tool 

-  did  not  have  the  time  once  arriving  on  board  to  devote 
sufficient  time  to  learning  the  system  well  enough  to  be 
able  to  use  it  as  a  management  tool 

-  Division  Officers  and  their  subordinates  were  the  real 
users  of  the  system,  not  Department  Heads 

At  the  levels  below  the  Department  Heads,  the  system 
is  being  used  extensively.  The  Division  Officers  maintain 
the  majority  of  their  required  administrative  records  and 
files  on  the  system.  It  was  stated  that  this  has  provided 
them  a  more  effective  and  efficient  way  to  manage  their 
div is  ion . 

2 .  Significant  Issues 

There  were  several  areas  of  concern  which  were 
identif ied : 


-  Support  was  not  being  provided  to  the  fleet  in  the  form 
of  recognizing  the  present  need  to  include  SNAP- II 
training  in  various  schools. 

-  Training  should  be  provided  to  all  levels  of  users  prior 
to  reporting  on  board. 

-  Standardization  is  lacking  in  the  depth  and  the  breath 
of  the  use  of  SNAP- II. 

-  The  system  has  become  the  routine  way  of  business  and 
that  the  overall  support  for  the  system  from  shore 
establishments  is  two  to  four  years  behind  the  fleet. 

-  A  PQS  program  needs  to  be  developed  for  the  various 
levels  of  users. 

-  There  is  an  inadequate  number  of  terminals. 


VI.  ANALYSIS  AND  DISCUSSION  OF  CASE  STUDIES 


The  issues  that  emerged  from  the  ship  reviews  will  be 
presented  in  two  different  sections:  an  overview  analysis  of 
the  case  studies  will  be  done,  and  from  these,  a  discussion 
of  specific  items  that  transcended  the  various  issues  in  the 
case  studies. 


A.  PROGRAM  PERSPECTIVE  AND  GENERAL  ISSUES 

Program  management  is  defined,  for  the  purposes  of  this 
thesis,  as  all  commands  external  to  the  users  command  that  are 
involved  in  the  procurement,  outfitting,  installation,  imple¬ 
mentation  and  operation  of  the  SNAP- 1 1  system  (Chapter  II 
presented  an  overview  of  the  program  management  organization). 
In  addition,  those  external  commands  that  directly  support  the 
ship's  supply,  maintenance  and  administrative  functions  (e.g., 
Naval  Supply  Centers,  Fleet  Accounting  and  Disbursing  Centers, 
Ship's  Intermediate  Maintenance  Activities,  Destroyer  Tenders, 
Navy  Finance  Center)  are  included  when  discussing  the  interface 
between  SNAP-II  and  the  shore  establishment. 

The  value  of  any  system  ultimately  rests  in  its  acceptance 
by  the  user.  User  satisfaction  is  the  key  determinant  when 
discussing  any  system's  benefits.  Across  the  board,  the  SNAP- 
II  system  is  viewed  as  a  tremendous  benefit  to  the  ships  in 
the  performance  of  those  functions  that  have  been  mechanized. 
Although  user  satisfaction  appeared  to  be  high,  there  was  a 
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considerable  amount  of  frustration  in  regard  to  various  aspects 
of  the  system.  From  the  afloat  vantage  point,  SNAP- I I  could 
be  significantly  better  than  it  is  today.  There  were  numerous 
problems  cited  and  issues  raised,  that,  when  viewed  in  totality, 
had  a  common  root  insofar  as  the  ships  were  concerned:  pro¬ 
gram  management.  This  may  be  a  misconception  on  their  part, 
but  there  is  a  certain  level  of  disenchantment  with  the  way 
the  program  is  being  managed.  In  and  of  itself,  this  is 
indicative  of  a  need  for  increased  and  effective  communication 
with  the  fleet  user. 

On  closer  observation,  the  satisfaction  and  enthusiasm 
for  the  system  was  mainly  at  the  functional  area  supervisor 
level.  Their  enthusiasm  appears  to  be  due  to  the  newness  of 
system  and  the  advantages  of  a  mechanized  approach  over  a 
manual  approach.  The  impression  is  that  as  these  users  become 
more  sophisticated,  they  will  be  less  willing  to  accept  the 
problems  they  have  encountered,  and  if  the  problems  persist 
or  recur,  their  enthusiasm  will  wane. 

The  ship's  managers,  on  the  other  hand,  are  less  satisfied 
with  the  system.  They  feel  for  the  most  part  that  SNAP- 1 1 
does  not  address  their  needs  as  managers.  Although  it  does 
provide  them  the  ability  to  manage  specific  operations,  it 
does  not  lend  itself  well  to  overall  management  of  their 
department  or  area  of  responsibility. 

At  the  command  level,  the  system  is  of  little  use  as  a 
decision  making  tool,  and  as  such  is  ignored.  The  system  was 
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not  regarded  as  being  able  to  provide  answers  to  ad  hoc 
questions.  Although  some  of  the  Commanding  Officers  and 
Executive  Officers  give  the  system  high  marks  in  the  area  of 
performance  of  specific  tasks  and  management  review  of  them, 
none  felt  that  it  was  of  use  to  them  in  guiding  the  ship 
toward  mission  accomplishment.  As  one  CO  pointed  out,  SNAP- 
II  was  just  another  way  of  doing  the  same  job. 

The  various  ranges  and  depths  indicated  in  the  summary 
Chapter  V  gives  an  indication  of  the  problem  associated  with 
assessing  the  status  of  SNAP-II  on  board  a  particular  ship. 

Due  to  a  lack  of  standardization,  each  ship  has  employed  SNAP- 
II  in  a  different  manner,  depending  on  the  importance  the 
command  (CO/XO)  attached  to  SNAP-II,  the  command  involvement 
in  the  management  of  the  system,  quality  of  "available" 
personnel ,  location  of  the  hardware  on  board,  and  many  other 
factors  peculiar  to  a  specific  ship.  Ships  are  at  different 
levels  of  utilizing  the  system  as  a  whole.  Kroenke  has  cate¬ 
gorized  computer  systems  according  to  how  they  are  employed  in 
the  management  of  an  organization  [Ref.  14:pp.  91-94]: 

-  Decision  Support  Systems  -  provides  for  ad  hoc  manipulation 
and  handling  of  data;  irregular  or  one  time  queries  for 
information  can  be  handled 

-  Management  Information  Systems  -  provides  past,  present 
and  future  information;  generates  preformatted  reports 
to  facilitate  management  decision  making 

-  Transaction  Processing  System  -  receives  and  records 
changes  to  a  data  base,  and  produces  appropriate  documents 

Some  ships  arc  basically  capable  of  effectively  utilizing  the 

system  to  process  transactions,  while  others  are  using  the 
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system  to  manage  the  transaction  processing,  and  there  are 
those  that  are  pushing  their  use  of  the  system  towards  the 
MIS  arena.  This  situation  is  exacerbated  by  having  each 
subsystem  employed  at  different  levels  within  any  ship. 

Though  the  comments  received  were  for  the  most  part 
localized  to  a  specific  problem  area,  there  were  a  number  of 
significant  issues  raised  that  apply  to  overall  management  of 
the  program.  The  ship's  have  serious  questions  in  each  of 
several  management  support  areas  that  drive  home  the  user's 
impression  that  SNAP- 1 1  planning  was  not  well  thought  out  and 
management  has  not  been  coordinated. 

In  this  context,  management  support  has  been  divided  into 
the  following  six  broad  areas: 

-  direction  of  program 

-  guidance  provided 

-  hardware/software  support 

-  training 

-  communication 

-  interface  with  shore  establishment 

Though  these  areas  are  arbitrary  and  do  not  relate  to  any 
charter  or  list  of  responsibilities,  they  serve  to  focus  in 
on  the  major  concerns  the  ships  have  with  the  SNAP-II  system. 
Each  area  will  be  discussed  and  the  significant  issues  (from 
the  ship's  viewpoint)  will  be  brought  out.  [Authors  note: 
System  management  terms  have  been  utilized  to  concisely  convey 
the  intent  or  meaning  of  what  various  personnel  felt  and  said- 
obviously,  they  did  not  use  them  themselves.]. 


Direction  of  Program 


1 . 

The  overall  direction  of  the  SNAP-II  program,  from  the 
ship's  perspective,  is  to  mechanize  manual  functions  in  the 
supply,  maintenance  and  administrative  areas.  They  do  not 
necessarily  view  it  as  an  effort  to  reduce  the  administrative 
burden  on  ships,  and  few  of  the  middle  level  managers  inter¬ 
viewed  saw  it  as  an  attempt  to  provide  management  capabilities 
in  performing  their  functions.  The  system  is  viewed  mainly  as 
a  Transaction  Processing  System  with  minimal  management  capa¬ 
bilities,  providing  only  those  management  capabilities 
necessary  to  manage  specific  operations.  It  is  not  perceived 
as  a  Management  Information  System  (MIS)  or  Decision  Support 
System  (DSS) ,  but  the  Command  level  and  middle  level  managers 
feel  that  it  should  perform  at  least  at  the  MIS  level. 

The  two  issues  that  weighed  most  heavily  on  the  minds 
of  the  interviewed  personnel  were:  the  lack  of  project  review 
by  program  management  at  the  ship  level  as  a  tool  to  guide 
the  direction  of  the  program,  and  whether  SNAP-II  was  intended 
to  be  a  Transaction  Processing  System,  Management  Information 
System,  or  a  Decision  Support  System.  The  issue  of  lack  of 
project  review  of  ships  with  SNAP-II  installed  will  be 
discussed  in  the  following  section  on  specific  emergent  issues 

The  issue  of  SNAP- 1 1 's  purpose  as  a  system  originates 


from  the  discontinuity  between  the  phrases  used  to  describe 
the  goals  and  attributes  of  the  SNAP-II  system  (e.g.,  real¬ 
time  MIS  [Ref.  1 : p .  1).  Automated  Information  System  [Ref. 


3:p.  1]  and  the  reality  of  what  the  system  can  do,  or  more 
importantly,  what  it  cannot  do.  The  managers  feel  that 
program  management  does  not  understand  the  needs  of  the  fleet 
with  regard  to  the  output  the  system  should  provide. 

If  it  is  assumed  that  SNAP- II  is  a  management  system, 
then  there  appears  to  be  a  dichotomy  between  its  purpose  and 
the  amount  of  hardware  provided  to  accomplish  this.  Namely, 
with  the  word  processing  capability  and  the  management  function 
superimposed  on  the  transaction  processing  system,  the  number 
of  terminals  appear  to  be  inadequate  to  handle  the  management 
function.  As  the  case  summaries  show'ed,  every  ship  felt  that 
they  did  not  have  an  adequate  number  of  terminals  to  perform 
the  functions  within  SNAP- II.  The  transaction  processing  and 
related  day-to-day  actions  by  managers  took  priority  and  sub¬ 
system  management  uses  and  word  processing  were  relegated  to 
a  "catch  as  catch  can"  status.  As  a  group,  the  middle  level 
managers  felt  word  processing  was  an  important  management  tool , 
yet  they  could  not  use  it  to  its  fullest  extent  due  to  the 
effects  it  had  on  system  performance  (response  time)  and 
transaction  processing. 

2 .  Program  Guidance 

For  the  purposes  of  this  review,  program  guidance 
covers  the  implementation  and  operational  guidance  received 
from  external  commands.  This  does  not  include  the  training 


of  personnel,  as  that  will  be  covered  in  a  separate  section. 
Although  each  ship  felt  program  guidance  was  inadequate,  this 


area  was  not  considered  a  key  issue  in  and  of  itself,  but  was 
in  the  background  of  most  emergent  issues.  It  is  discussed 
because  it  serves  to  provide  a  background  that  is  relevant  in 
other  areas  that  were  identified  by  the  individual  ships. 

As  stated  in  various  cases,  the  implementation  process 
that  NAVMASSO  oversees  is  considered  to  be  good  by  the  ships 
reviewed,  and  was  not  a  major  issue  except  as  it  related  to 
documentation  and  training.  These  two  issues  will  be  discussed 
in  the  next  section  on  specific  emergent  issues. 

The  operational  guidance  which  is  within  the  purview 
of  the  ship's  chain  of  command  and  the  supporting  shore 
establishment  (refer  to  Figures  (3)  and  (4)  in  Chapter  II)  was 
considered  as  inadequate  or  non-existent.  The  Type  Commanders 
were  the  only  bright  spot  in  the  process.  They  have  provided 
guidance,  but,  as  with  any  new  program,  it  was  not  timely  or 
in  sufficient  depth.  The  Executive  Officer  of  a  destroyer 
noted  that  the  ship  had  been  waiting  "two  years"  for  the 
guidance  that  the  "Annex  W  of  SURFSUP"  was  going  to  provide. 

Unlike  the  Type  Commanders,  the  shore  establishment 
has  not  provided  guidance  on  how  to  effect ively  integrate 
SNAP-II  into  the  shipboard  routine.  The  functional  managers 
have  not  updated  basic  publications  (e.g.  NAVSUP  Manuals,  5-M 
Manuals)  to  include  policy  or  procedural  guidelines.  Some  of 
the  ships  have  had  SNAP-II  on  board  for  two  years  and  are 
still  waiting  for  this  basic  guidance. 


3 .  Hardware  and  Software  Support 

The  ships  did  not  report  many  problems  with  the 
hardware  and  it  was  considered  very  reliable  (Chapter  III  pro¬ 
vides  background  information  on  hardware  and  software) . 

Another  bright  spot  in  the  whole  program  is  the  support  the 
ship  receives  in  the  maintenance  of  hardware  and  software.  As 
noted  in  each  of  the  cases,  the  performance  of  both  NAVSEACENS, 
NAVMASSO,  and  NAVMASSO  DETPAC  has  been  outstanding  in  the  area 
of  response  to  problems  and  questions.  As  documented  in  Case 
Five,  ships  had  stories  of  superlative  effort  put  forth  to 
support  them  when  they  needed  it.  The  software,  although 
there  were  numerous  problems,  was  not  a  major  issue  to  most 
ships.  The  users  had  a  tremendous  number  of  suggestions  to 
improve  the  subsystems  and  identified  numerous  problems  with 
programs  (all  at  the  procedural  level).  No  major  problems 
were  cited  that  had  not  previously  been  identified  by  NAVMASSO. 
As  stated  previously,  the  users  at  the  lower  levels  are 
impressed  with  the  functions  performed  by  the  software. 

The  issue  that  dominated  any  discussion  of  software 
was  that  of  documentation.  Documentation  was  considered 
inadequate  for  training  and  of  little  value  for  problem 
solving  and  as  a  general  reference.  Documentation  will  be 
discussed  in  greater  detail  in  Section  B  of  this  chapter. 

4 .  Personnel  and  Training 

The  subject  of  personnel  was  not  a  major  issue,  other 


than  as  it  related  to  training  (Chapter  III  provides 


background  information  on  personnel  and  training).  The 
concept  of  using  collateral  duty  personnel  to  run  and  maintain 
the  SNAP- 1 1  system,  with  exception  of  relatively  few  comments, 
was  felt  to  be  sound.  Although  a  number  of  system  coordinators 
and  maintainers  felt  that  it  could  affect  their  primary 
functions,  no  data  or  documentation  was  provided  to  support 
their  feelings.  It  is  felt  that  there  will  be  incidences 
where  it  will  affect  the  support  of  SNAP- II,  but  they  do  not 
warrant  a  change  in  policy  at  this  time.  The  most  frequently 
discussed  issue  and  the  one  with  the  most  immediate  concern 
was  training.  Their  criticism  of  program  management  crystal¬ 
lized  with  the  topic  of  training.  Training  will  be  discussed 
in  Section  B  of  this  chapter. 

5 .  Communication 

The  area  of  communication  was  not  the  subject  of  much 
discussion  by  itself,  but  was  linked  to  almost  every  other 
issue  that  surfaced.  To  that  extent,  it  is  an  underlying 
cause  of,  or  a  result  of  each  issue  that  the  ships  surfaced. 
From  the  afloat  viewpoint,  there  is  a  lack  of  communication 
at  all  levels  and  in  all  management  areas  of  the  SNAP- 1 1 
program.  The  issues  raised  were:  lack  of  fleet  input,  lack 
of  dialog  with  the  fleet  on  matters  concerning  operations, 
and  the  lack  of  understanding  of  the  program's  decision 
making  process  in  the  fleet. 

Most  of  the  managerial  personnel  feel  that  the  program 


got  off  to  a  bad  start  as  a  result  of  a  lack  of  good  fleet 


input  or  input  that  appeared  to  be  ignored  by  the  program 
management  (Case  Six  presents  a  good  example  of  this  view). 
Instead,  program  development  was  controlled  by  personnel  who 
were  too  far  removed  from  the  realities  of  shipboard  life  and 
who  relied  on  manuals  to  provide  the  necessary  guidance.  To 
managerial  personnel,  the  system  was  not  developed  to  meet 
shipboard  needs  as  they  view  , t. 

Until  recently,  there  was  little  effort  to  have  a 
dialog  with  the  fleet  concerning  the  problems  and  issues  they 
have,  or  to  provide  them  information  on  the  status  of  problems 
or  expected  changes  to  the  system.  There  is  little  in  the 
way  of  public  relations  concerning  SNAP-IJ  aimed  either  at  the 
ships  or  at  the  shore  establishment. 

The  cases  disclosed  that  the  fleet  has  very  scant 
knowledge  of  the  infrastructure  of  the  SNAP- 1 1  program  and 
little  information  on  the  decision  making  process.  To  the 
ships,  the  SNAP- 1 1  program  is  embodied  by  NAVSEACEN  and 
NAVMASSO,  with  the  TYCOM  playing  its  traditional  role  of 
monitoring  the  problems  associated  with  SNAP- II.  Prom  the 
end  user  viewpoint  the  power  to  make  decisions  rests  with 
NAVSEA  for  hardware  and  NAVMASSO  for  software  and  all  other 
concerns. 

6 .  Interface  with  Supporting  Shore  Establishment 


The  interface  consists  of  the  way  in  which  the  ship 
and  the  supporting  shore  establishment  pass  requirements  and 
information.  The  issue  here  lies  with  the  way  the  external 


activities  provide  services  or  assistance.  This  interface  is 
in  the  manual  mode  and  not  prepared  to  handle  the  mechanised 
output  from  SNAP- II.  This  problem  has  been  noted  by  several 
of  the  ships  visited.  Specifically,  the  maintenance  activitie 
(e.g.,  dealing  with  work  packages,  RAV) ,  supply  activities 
(e.g.,  dealing  with  requisition  processing,  status  on  pro¬ 
curements)  and  financial  activities  (e.g.,  dealing  with 
processing  of  obligations,  reconciliation  of  expenditures) 
cannot  or  do  not  accept  the  mechanized  output  of  SNAP-II. 

These  activities  are,  for  the  most  part,  in  the  manual  mode 
of  communicating  with  ships. 

Another  shortcoming  of  the  system  is  the  lack  of  use 
of  telecommunications  to  support  the  ship  while  at  sea  and 
while  in  port.  On  board  ship,  various  processes  could  com¬ 
municate  directly.  For  example,  it  is  archaic  to  create  an 
outgoing  message  on  SNAP-II,  punch  a  paper  tape,  carry  the 
paper  tape  to  radio  central  to  be  fed  into  a  machine  to  be 
transmitted  off  the  ship.  Also,  the  ship  does  not  have  the 
capability  to  communicate  directly,  via  telephone  lines,  with 
supporting  activities  when  it  is  in  port. 

R.  SPF.CIFIC  F.MHRGFNT  ISSUES 

The  previous  section  gave  an  overview  and  analysis  of  the 
issues  raised  by  the  ships.  This  section  will  focus  on  those 
issues  that  have  had  the  greatest  impact  on  the  integration 
of  the  SNAP- I i  system  and  transcend  many  of  the  issues  raised 


hv  the  end  user. 


* 
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1 .  Project  Review,  Management  Policy,  and  Standards 

Management  policy  for  the  use  (vice  management  of)  of 
SNAP- II  system  was  an  item  of  concern  in  many  of  the  ships 
reviewed.  The  subject  of  project  review,  although  brought  up 
only  as  a  tangential  issue  in  several  cases,  in  and  of  itself 
was  nevertheless  conspicuous  by  its  absence.  These  two  issues 
are  closely  related,  as  the  review  process  must  have  some 
standard  to  be  compared  with,  and  these  standards  are  driven 
by  policy  decisions.  As  one  Commanding  Officer  noted,  the 
interviews  herein  were  the  first  time  someone  external  to  his 
ship  had  been  aboard  specifically  and  formally  to  inquire  as 
to  how  the  various  aspects  of  SNAP- 1 1  were  performing  in  his 
command . 

a.  Need  for  Project  Review 

Any  computer  project  has  risks.  Among  other 
definitions,  risk  is  def ined  by  Cash,  et  al  [Ref.  15:p.  515] 
as : 

-  failure  to  obtain  all,  or  even  any  of  the  intended  benefits 

-  increased  costs  of  implementation 

-  longer  time  for  implementation 

-  technical  performance  of  system  below  estimates. 

To  reduce  the  risk  inherent  in  any  project,  proper 
management  tools  must  be  brought  to  bear  to  control  the  project. 
From  a  systems  point  of  view,  Senn  defines  a  control  model 
as  [Ref.  16:pp.  12-15]: 

-  a  standard  for  acceptable  performance 

-  a  method  of  measuring  actual  performance 

-  a  means  of  comparing  actual  performance  against  the 

standard 

-  a  method  of  feedback. 
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Senn  further  categorizes  the  formal  process  of  determining  how 
well  the  system  is  working,  how  it  has  been  accepted  and 
whether  adjustments  are  needed  as  "post  implementation  review" 
[Ref.  16:p.  542].  In  this  context,  "post  implementation 
review"  can  be  regarded  as  a  feedback  method  to  determine  if 
the  actual  installed  and  working  computer  system  is  doing  what 
it  was  designed  to  do.  A  case  study  advanced  by  Cash  et  al 
[Ref.  15:p.  557]  places  post  implementation  review  as  part  of 
the  control  and  monitoring  process,  ivhich  is  analogous  to  the 
system  feedback  concept. 

As  established,  the  only  feedback  provided  for  in 
the  current  SNAP-II  program  is  a  reactionary  one--i.e.,  ships 
generate  reports  describing  trouble  with  hardware  or  software, 
or  suggesting  changes  to  some  aspect  of  the  system.  While 
there  is  informal  liaison  maintained  by  XAVMASSO  implementation 
personnel  after  installation,  there  is  no  formalized  or  "active 
review  process.  Periodic  meetings  are  conducted  on  a  geo¬ 
graphic  basis  to  discuss  system  problems  or  new  developments, 
with  fleet  attendance  highly  encouraged,  but  not  mandatory. 
"Technical  Advisories"  and  "Fleet  Bulletins"  arc  also 
published  by  various  sources. 

A  post  implementation  review  can  be  used  as  feedback 
to  improve  system  effectiveness  and  attain  the  bottom  line  of 
user  satisfaction.  Various  authors  have  outlined  both  the 
need  for  post  implementation  reviews  and  the  general  character 
they  should  take.  Caydasch  has  formulated  what  he  terms  a 


"quick  and  easy  approach"  to  this  process  [Ref.  1 7 : pp .  54-55], 
maintaining  that  the  review,  or  audit,  should  be  performed 
after  the  system  has  had  a  chance  to  "settle  down".  The  general 
outline  of  his  recommendation  are  as  follows: 

-  compare  promises  to  deliverables 

-  monitor  operational  performance  through  observation 

-  evaluate  the  quality  of  information 

-  evaluate  security,  backup  and  recovery  provisions 

-  determine  adequacy  of  system  documentation 

-  interview  users 

As  a  result  of  this,  the  review  should  reveal  system  problems 
and  recommendations  from  the  users.  Both  are  vital  for 
continuity  of  system  expansion  and  growth.  More  detailed 
recommendations  for  what  a  post  implementation  review  can 
entail  can  be  found  in  works  by  Senn  [Ref.  16:pp.  542-547]  and 
Lucas  [Ref.  18:pp.  515-521]. 

b.  Policy  and  Standards 

(1)  Measurement .  In  following  the  system  model, 
a  post  implementation  review  serves  to  measure  the  actual 
performance  of  a  system  against  a  standard,  or  what  it  was 
intended  to  accomplish.  As  a  result  of  this  comparison, 
positive  action  can  be  taken  to  correct  any  discrepancies 
d  iscovered . 

Defining  exactly  what  the  SNAP- 1 1  system  was 
intended  to  do  may  be  difficult.  From  one  aspect,  one  may 
simply  state  that  if  it  accomplishes  the  specific  functions 
it  was  programmed  to  do,  then  it  is  a  success.  How’ever,  the 
programming  or  software  function  is  just  one  part  of  a  computer 
system.  As  defined  by  Kroenke  [Ref.  14:p.  22],  hardware, 


software,  data,  procedures  and  personnel  constitute  a  computer 
system.  Therefore,  to  measure  the  effectiveness  of  the  system 
all  must  be  measured  against  a  standard. 

(2)  Standards .  As  the  SNAP- 1 1  program  has  been 
implemented,  it  appears  that  only  four  of  the  five  components 
of  a  computer  system  as  defined  by  Kroenke  have  some  standard 
established.  Hardware,  software,  and  data  are  sufficiently 
defined  and  standardized  by  project  documentation.  The  pro¬ 
gram  implementation  document  and  Type  Commanders  instructions 
specify  what  personnel  shall  be  used  and  what  training  they 
will  receive.  From  a  system  viewpoint,  procedures  are 
partially  unspecified.  Certainly,  there  are  procedures 
specified  as  to  how  to  run  and  manage  the  system  itself,  but 
there  is  no  guidance  as  to  how  to  integrate  the  SNAP- 1 1  system 
procedurally  into  the  overall  current  ships  organization  and 
operation . 

There  are  two  directions  from  where  procedural 
or  policy  guidance  and  standards  for  SNAP-II  integration  into 
the  organization  can  come  from:  the  ship's  administrative 
commander  (i.e..  Type  Commander)  and  the  shore  establishment, 
which  has  cognizance  over  Navy-wide  management  and  support 
systems,  such  as  the  supply  and  maintenance  systems. 

Frustration  was  evident  in  all  reviews 
because  of  a  lack  of  policy  guidance  as  to  how  to  integrate 
the  SNAP-II  system  into  the  management  of  the  ship.  Kroenke 
has  categorized  computer  systems  according  to  how  they  are 


employed  in  the  managment  of  an  organization,  as  cited 
previously.  Some  ships  are  utilizing  the  system  as  a  trans¬ 
action  processing  system,  while  some  are  a  level  above  and 
attempting  to  use  it  as  a  management  information  system.  Some 
standard  or  policy  must  be  established  so  that  system  use  is 
uniform  and  fleet  units  can  use  the  SNAP-II  system  to  its  full 
potential . 

There  is  little  or  no  policy  guidance  as  to 
how  the  SNAP-II  system  is  to  be  integrated  with  shore  establish 
ment  responsible  for  supporting  the  fleet.  This  has  been 
commented  on  in  various  ships  in  relation  to  the  3-M  System 
and  the  supply  organization,  and  has  been  evidenced  through 
ships  still  being  required  to  furnish  "hard  copy”  documents 
to  shore  activities  to  accomplish  maintenance  actions,  such  as 
work  requests  (OPNAV  4790/2K)  and  measure  calibration. 

Further,  several  ships  report  that  the  shore  establishment 
is  not  prepared  to  deal  with  an  automated  ship,  and  does  not 
fully  understand  what  the  SNAP-II  system  is  capable  of  doing. 

2 .  Documentat ion 

The  issue  of  documentation  was  raised  from  two  view¬ 
points:  inadequacy  of  documentation  to  assist  and  educate 

the  manager,  and  that  existing  documentation  suffers  from  a 
lack  of  readability  and  organization.  The  later  may  well  be 
the  cause  of  the  former. 

The  inadequacy  of  the  existing  documentation  was  cited 
as  a  specific  area  of  concern  throughout  the  reviews,  being 


identified  as  an  aggravating  factor  in  the  areas  of  management 
and  training  in  relation  to  the  SNAP- II  system . 

a.  Management  Perception 

The  underlying  reasons  for  the  dissatisfaction 
with  the  current  documentation  are'  varied  in  nature.  Generally, 
the  data-entry  personnel  are  not  reported  as  having  problems 
with  documentation,  only  the  personnel  concerned  with  management 
Specific  attributes  of  the  documentation  and  circumstances  were 
not  cited,  just  a  general  lack  of  confidence  and  use  brought 
on  by  negative  initial  impressions. 

In  this  sense,  the  documentation  provided  was 
viewed  as  adequate  for  guiding  personnel  in  the  entry  of 
specific  data  in  specific  menu-driven  screens,  but  of  limited 
use  in  answering  questions  or  as  a  management  tool. 

The  managers  expressed  concern  that  the  documen¬ 
tation  was  hard  to  use  and  difficult  to  understand.  They  felt 
it  was  written  for  "computer  literate"  people,  finding  the 
terminology  confusing  and  lacking  a  management  summary.  They 
could  not  easily  reference  the  document  for  questions  of  a 
broad  nature  and  the  documentation  did  not  illustrate  the 
inter-relationships  between  subsystems  and  data. 

b.  Management  Needs 

From  a  management  perspective,  the  guides  and 
manuals  provided  arc  inadequate.  This  has  been  brought  up 
repeatedly  in  the  case  studies  and  cited  as  a  primary  reason 
as  to  why  middle  level  managers  and  Command  level  personnel 


have  not  utilized  or  integrated  the  SNAP- 1 1  system  to  its 
full  potential.  There  is  no  documentation  available  that  gives 
information  a  manager  can  use  effectively;  it  appears  that  all 
documentation  is  geared  either  to  the  data  entry  user  or  as  a 
reference  document  for  hardware  and/or  software  maintenance. 

Managers,  as  a  group,  have  specific  tasks  and  needs 
in  relation  to  an  information  system  that  should  be  identifiabl 
Cohen  and  Cunningham  discuss  the  creation  of  effective  manuals 
for  specific  readers  to  perform  specific  tasks  [Ref.  1 9 : p .  I]. 

Expanding  on  this,  they  maintain  that  different  users  need 
different  information,  with  many  ways  to  classify  manuals- - 
according  to  type  of  job,  location,  and  intended  audience 
[Ref.  1 9 : p .  X] .  The  existent  SNAP-II  documentation  docs  not 
single  out  specific  groups  of  users  or  provide  guidance  and 
reference  tailored  to  specific  needs.  While  the  information 
is  all  there,  it  is  essentially  "buried"  and  managers  are 
loathe  to  dig  through  the  documentation  to  extract  what  they 
can  use. 

If  the  system  is  to  succeed,  management  must 
understand  it  and  be  able  to  use  it.  Perryman  notes  that  the 
quality  of  documentation  is  a  major  determinant  of  how  well  a 
system  is  received  and  how  widely  it  is  used  [Ref.  20:p.  55]. 
McCann  [Ref.  2 1 : p .  8]  also  places  emphasis  on  the  quality  of 
system  user  documentation  in  improving  the  benefit  derived 
from  a  computer  system. 


c.  Training 

The  adaptability  of  documentation  to  the  training 
environment  was  brought  up  as  an  issue.  In  the  present  format, 
it  was  not  viewed  as  a  training  document  because  it  is  oriented 
mostly  as  a  reference,  and  was  not  suitably  arranged  by  topic 
area.  An  idea  advanced  by  Cohen  and  Cunningham  is  the  concept 
of  "bridging"  the  old  system  to  the  new  one  [Ref.  1 9 :  p .  157]. 
Under  this  concept,  the  user  of  the  documentation  should  be 
given  an  explanation  and  example  of  the  "old"  and  "new"  at  the 
same  time.  Applying  this  to  the  SNAP- 1 1  system,  there  is  very 
little  graphic  display  of  what  the  "old"  manual  forms  looked 
like  and  where  information  was  entered  on  it,  and  how  this 
relates  to  the  SNAP-II  system.  It  would  be  of  great  value  in 
training  new  users  who  are  presumed  to  have  knowledge  of  manual 
system  procedures. 

d.  Source  of  Documentation 

The  directives  that  NAVMASSO  has  promulgated  con¬ 
cerning  the  development  of  end-user  documentation  [Ref.  22], 
and  [Ref.  25]  comply  with  the  standards  established  by  the 
Secretary  of  the  Navy  [Ref.  24:Encl.  (1)].  On  examination, 
these  standards  specify  only  the  format  of  the  documentation, 
and  does  not  address  itself  specifically  as  to  whom  the 
documentation  is  aimed,  stylistic  content  or  provide  guidance 
as  to  what  constitutes  "good"  user  documentat ion . 

As  these  standards  were  developed  prior  to  or 
during  1979  (pre-SNAP  era),  they  may  have  been  intended 


specifically  for  use  by  data-processing  professionals  who  have 
initial  understanding  about  computer  systems.  Since  that  time 
the  advent  of  computer  systems  (such  as  SNAP- 1 1)  where  novice 
end-users  are  placed  in  an  interactive  status  requires  a  whole 
new  approach  to  documentat ion- - the  target  audience  is  a 
completely  different  one. 

e.  Existing  Documentation 

There  are  four  types  of  documentation  available 
to  the  fleet  user  for  SNAP- II: 

-  SNAP- 1 1  Management  Guide 

-  On-line  Users  Manual 

-  Users  Guide 

-  Desk  Top  Guide 

With  the  exception  of  the  management  guide,  there  are  separate 
manuals  and  guides  for  each  subsystem  of  the  SNAP- 1 1  system. 

The  management  guide  gives  a  brief  introduction 
to  the  SNAP-II  system,  history  of  software  releases,  and  a 
brief,  general  description  of  each  subsystem  without  reference 
to  specific  input  or  output.  It  could  be  confusing  to  a  new 
manager/user,  as  it  is  interspersed  with  computer  terms  and 
does  not  state  exactly  what  the  system  can  do  for  a  manager. 

It  is  geared  toward  managing  the  SNAP-II  system,  not  managing 
with  the  SNAP-II  system. 

The  on-line  users  manual  is  essentially  a  printed 
version  of  the  system's  on-line  "AID"  feature,  with  the 
objective  of  providing  information  to  the  user  so  he  can  use 
the  particular  subsystem  effectively.  Little  use  is  made  of 
graphics  (except  for  type  written  screen  examples),  with  text 


filling  the  entire  page.  The  content  is  organized  using 
engineering  notation  (e.g.,  5.1.5.2.1.16),  without  breaks 
between  subjects,  or  tabs  provided  for  easy  subject  or 
category  reference.  The  approach  to  explaining  the  use  of 
the  subsystem  is  "top  down",  i.e.,  it  starts  at  the  entry 
point  to  the  subsystem  and  goes  down  through  each  module,  sub- 
module,  etc.,  with  screen  numbers  used  as  reference,  explaining 
how  to  input  data  to  each  individual  data  entry  screen.  Table 
V  is  a  typical  example  [Ref.  19].  A  review  of  one  manual, 
the  Maintenance  Data  Subsystem  on-line  users  manual  [Ref.  24] 
showed  a  text  of  862  pages,  with  the  table  of  contents 
(example  in  Table  VI)  alone  running  27  pages.  The  documentation 
is  very  complete--it  tells  a  user  everything  that  is  applicable 
to  a  subsystem.  Herein  lies  the  paradox--it  overwhelms  the 
reader  by  being  too  complete  and  hides  information  by  virtue 
of  poor  format. 

The  users  guide  is  a  reference  document  intended 
for  users  having  knowledge  of  the  system  in  the  first  place. 

It  lists  and  cross  references  files  and  programs,  gives  data 
element  configurations,  and  lists  error  messages  and  corrective 
actions.  Of  all  the  documentation,  this  is  the  only  one  that 
lists  the  reports  available  from  a  subsystem  in  one  place. 

The  desk  top  guide  is  a  self-study  document  for 
new  users.  It  is  set  up  for  a  user  to  learn  and  master 
specific  functions,  but  does  not  give  a  system  overview. 


TABLE  V 


EXAMPLE  OF  PAGE  OF  ON-LINE  USERS  MANUAL 


3. 2. 2. 2. 2. 2  Online  Tickler  Report  by  Item  ID  (MDS490).  This  screen  presents 
a  summary  or  recoros  chat  tall  within  the  range  or  niter  values  specified. 
The  summary  includes  item  ID,  management  code,  description,  worn  center  and 
due  date.  This  screen  allows  you  to  display  a  selected  record  (determined  by 
cursor  position)  on  a  data  display  screen.  PFKey  options  available  from  this 
screen  are  described  below. 


REFERENCE 

PARAGRAPH 

PP1  -  Review  Record  3. 2. 2. 2. 2. 3 

(This  option  presents  a  data  display  screen 
prefilled  with  data  fron  the  cursor-specified 
record.) 

PF9  -  First  mge 

(Depressing  this  option  causes  the  first  page  of 
the  report  to  be  displayed.  If  the  report  does 
not  have  multiple  pages,  this  option  will  not  be 
available. ) 

PF12  -  Next  Page 

(Depressing  this  option  causes  the  next  page  of 
the  report  to  be  displayed.  If  no  additional 
pages  remain,  this  option  will  not  be  available.) 

Additional  PFXeys  available  are  PF13  for  general  aid  as  described  in 
paragraph  3.1.3,  and  PFKeys  14,  15,  ano  16  as  described  in  paragraph  2.1.4.4c. 

3. 2. 2. 2. 2. 3  Review  Record  for  Report  by  Item  ID  (MDS508).  This  screen 

presents  a  data  display  of  the  record  selected  from  the  Crime  Tickler  Report 
by  Item  suimary  screen.  Fields  will  be  prefilled  with  existing  data  and 
nonmodifiable.  Selection  of  EKTER  will  return  to  the  surma  ry  screen. 
Additional  PFKeys  available  are  PF13  foe  general  aid  as  described  in  paragraph 
3.1.3,  and  PFKeys  14,  15,  and  16  as  described  m  paragraph  2.1.4.4c. 

3. 2. 2. 2. 2. 4  Select  Options  for  Report  by  Date  Due  (MDS492).  This  filter 

screen  enables  you  to  select  a  specific  range  of  records  for  the  on-line 
report  by  date  due.  Values  that  may  be  entered  are  beginning  and  ending  Item 
ID' 3,  beginning  and  ending  Due  Dates,  a  Modified  Since  Date,  specific 
Management  Cooes  and/or  work  centers  (you  must  change  the  fields  to  *Y*).  The 
first  work  center  field  will  be  prefilled  with  your  primary  work  center.  If 
you  have  multiple  work  center  access,  this  field  will  oe  modifiable.  Fields 
may  be  left  blank.  If  fields  are  left  blank,  all  values  for  those  fields  will 
be  eligible  for  selection.  Date  value,  if  entered,  mist  be  in  DD  MMM  Ti 
format.  Selection  of  EKTER  initiates  validation  of  the  filter  values 
entered.  If  any  field  is  in  error,  the  filter  screen  is  redisplayed  with 
invalid  fields  Dlinking.  Viien  no  errors  exist,  record  selection  Degins. 
Records  meeting  the  range  of  filter  values  are  displayed  on  the  Online  Tickler 

Report  by  Date  Due  summary  screen  (refer  to  paragraph  3. 2. 2. 2. 2. 5) .  If  no 

records  qualify,  the  filter  screen  is  redisplayed  with  the  message,  *NO 
gUALIFYING  TICXLER  RECORDS  FOUND*.  Additional  PFKeys  available  are  PF13  for 
general  aid  as  oesenoea  in  paragraph  3.1.3,  and  PFKeys  15  ana  16  as  described 
m  paragraph  2.1.4.4c. 
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TABLE  VI 

EXAMPLE  OF  PAGE  FROM  TABLE  OF  CONTENTS 


TABLE  OP  ODNTEMTS  (cont.) 


3. 2. 2. 2. 3. 2  Select  Options  for  Tickler  369 

Modification  (MDS482) 

3. 2. 2. 2. 3. 3  Summary  of  Items  for  Modification  372 

(MDS484) 

3. 2. 2. 2. 3. 4  Modify  Tickler  Pile  Record  (MDS486)  372 

3. 2. 2. 2. 3. 5  Review  Tickler  Record  for  Modification  375 

(HDS657) 

3. 2. 2. 2. 3. 6  Delete  Tickler  Record  Verification  375 

(MDSS14) 

3. 2. 2.3  Add  New  ship's  Tickler  Pile  (MDS465)  375 

3. 2. 2. 4  Delete  Tickler  Pile  Selection  (MDS467)  379 

3. 2. 2. 4.1  Delete  Tickler  Pile  Verification  379 

(MDS477) 

3.2. 2.5  Order  Nonmaintenance  Related  Supplies  379 

3.2.3  equipment  Configuration  and  Logistics  382 

Support  (MDS442) 

3.2. 3.1  On-line  equipment  configuration  Reports  385 

Menu  (MDS819) 

3. 2. 3. 1.1  On-line  Report  equipment  System  387 

Identification  (MDS821) 

3. 2. 3. 1.1.1  On-line  Report  Equipment  system  Ident  389 

by  SWUM  (MDS831) 

3. 2. 3. 1.1. 2  On-line  Report  Equipment  System  391 

Identification  by  APL  (MDS823) 

3. 2. 3. 1.2  on-line  Report  APL  Summary  List  393 

(MDS825) 

3. 2. 3. 1.3  On-line  Report  Restrict  Equipment  Pile  395 

Search  Options  ((OS861) 

3. 2. 3. 1-3.1  Equipment  Pile  Search  Warning  395 

(MDS835) 

3. 2. 3. 1.4  Find  Eqpt  by  Logistics  Support  Data  for  398 

Bqpt  Update  (MDS908) 

3. 2. 3. 1.5  On-line  Report  .Equipment  Suamary  List  400 

(MDS827) 

3. 2. 3. 1.6  On-line  Report  APL  Characteristics  Data  400 

(MDS860) 

3. 2. 3. 1.7  On-line  Report  Detailed  Equipment  Data  404 

(MDS829) 

3. 2. 3. 1.8  Additional  Equipment  Data  (MDS849)  404 

3. 2. 3. 1.9  General  Logistics  Support  Data  surtnary  407 

(MDS912)  • 

3. 2. 3. 1.9.1  Equipment  XREF  For  Logistics  Data  Item  407 

(MDS910) 

3. 2. 3. 1.9. 2  General  Logistics  Support  Data  Detail  411 

(MDS911) 

3.2.3.1.10  Equip  Dependent  Logistics  Data  Suamary  411 

(MDS931) 
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f.  Documentation  Design 

It  would  appear  that  the  designers  of  the  system 
have  taken  considerable  effort  to  ensure  "user  friendliness" 
through  the  design  of  system  architecture  and  user- interface , 
but  have  neglected  documentation.  Hulme  [Ref.  26:p.  57] 
states : 

The  ease  of  understanding  a  piece  of  written  material  will 
depend  not  only  in  the  characteristics  of  the  passage,  e.g., 
how  clearly  it  is  printed,  its  grammatical  form,  etc.,  but 
also  upon  the  readers  past  experience  and  familiarity  with 
the  concepts  involved. 

Various  authors  have  stressed  the  importance  of 
using  plain  English  without  technical  jargon  in  system 
documentation  [Ref.  19:p.  6]  and  [Ref.  20:pp.  56-57].  The 
existing  SNAP- II  documentation  is  replete  with  "computerese"; 
"cursor  selected",  "screen  fields",  "selected  data  type", 

"card  image  format"  and  similar  terms  appear  all  too  often, 
and  serve  to  confuse  the  reader.  Excessive  internal  cross 
referencing  is  also  a  detracting  factor. 

Format  and  organization  of  text  can  be  extremely 
important.  For  example,  in  one  passage  from  the  MDS  on-line 
users  manual,  the  explanation  for  one  screen  is  a  solid  block 
of  text  running  half  the  page,  single  spaced.  Perryman 
recommends  that  text  be  uncluttered,  neat  with  wide  margins, 
and  that  it  be  complimented  with  effective  charts  and  diagrams 
[Ref.  20:p.  58].  The  physical  separation  of  chapters  (e.g. 
visual  cue]  is  also  recommended,  which  is  lacking  in  SNAP- I  I 


documentat  ion . 
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5 .  Training 

a.  Strategy 

In  the  overall  training  strategy  of  the  SNAP- 1 1 
system,  NAVMASSO  is  tasked  with  providing  the  initial 
implementation  training  for  the  end  users  on  board  ship.  The 
formal  training  relationship  with  NAVMASSO  is  complete  upon 
implementation,  and  by  extension,  NAVMASSO  will  be  out  of  the 
training  business  when  all  ships  have  had  SNAP- II  implemented. 
Concurrent  with  the  phase-out  of  NAVMASSO  in  the  formal 
training  arena  is  the  emergence  of  formal  training  responsi¬ 
bilities  within  the  Navy  training  establishment. 

As  of  January  1986,  the  Navy  training  establishment 
has  not  commenced  a  full  scale  training  effort  for  the  SNAP- 1 1 
program.  Various  training  commands  and  schools  have  included 
some  SNAP-II  training  to  one  degree  or  another,  but  not  all 
have  integrated  SNAP-II  either  specifically  or  as  a  subset  to 
current  instruction  or  subject  areas.  In  and  of  itself,  even 
though  formal  training  has  lagged  implementation  by  several 
years,  this  overall  strategy  is  not  seen  as  having  had  a 
deleterious  effect  on  the  success  of  the  SNAP-II  program,  due 
to  the  effort  by  NAVMASSO  to  assist  informally  after  imple¬ 
mentation  and  because  of  the  relative  lack  of  sophisticated 
employment  of  the  system  by  fleet  users  at  this  point  in  the 
life  of  the  SNAP-II  system.  This  has,  however,  limited  the 
ability  of  some  ships  to  fully  utilize  the  SNAP-II  system  and 
derive  its  intended  benefits.  This  strategy  and  current  status 
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of  training  should,  however,  be  communicated  formally  to  fleet 
users  so  that  they  will  not  become  complacent  and  allow  the 
system  to  stagnate  or  digress. 


b.  Thrust  of  Training 

The  emphasis  of  the  training  for  the  SNAP- 1 1  system 
should  focus  on  the  type  of  training  and  long  term  objectives, 
with  "Who"  is  conducting  the  training  as  a  minor  issue.  The 
concept  of  training  in  relation  to  a  computer  system  can  assume 
diverse  perspectives.  Differentiation  can  be  made  between 
users  and  managers  [Ref.  27:p.  30],  initial  versus  recurring 
training  [Ref.  14:p.  63],  system  versus  application  (or 
product)  training  [Ref.  16:p.  528],  and  concept  development 
versus  specific  skill  training  [Ref.  27:p.  32].  All  of  the 
aforementioned  must  be  considered  when  designing  and  imple¬ 
menting  a  training  program  for  a  computer  system.  The  success 
or  failure  of  the  system,  or  its  effectiveness  and  efficiency, 
can  be  driven  by  the  training  afforded  the  end  user  [Ref.  14: 
p.  64].  In  its  current  state,  managers  as  a  group  are  not 
being  trained. 

(1)  User  vs.  Manager  Training.  Under  the  current 
implementation  strategy,  NAVMASSO  is  tasked  with  providing 
the  initial  end-user  training  in  order  to  place  the  SNAP- I  I 
system  in  an  operational  status.  There  ls  no  sub-strategy  as 
to  what  kind  of  end  user  is  being  dealt  with.  As  in  the 
documentation  issue,  training  should  be  tailored  to  the 
function  of  the  end  user  in  question.  The  Commanding  Officer 


or  a  Department  Head  will  have  different  views  of  the  system 
than  a  data  entry  user,  and  should  be  trained  with  their 
different  perspectives  in  mind.  The  relationship  of  training 
to  documentat ion ,  however,  should  not  be  regarded  such  that 
one  is  a  substitute  for  the  other.  Senn  warns  that  good 
documentation  should  not  be  a  substitute  for  training  [Ref. 

16 : p .  528]. 

(2)  Recurrent  Training.  Once  implementation 
training  has  been  accomplished,  the  end  user  should  net  be 
left  on  his  own  nor  should  training  be  regarded  as  complete. 

Both  Eibes  and  Kroenke  address  the  idea  of  recurrent  training. 
Eibes  [Ref.  27:pp.  30-53]  recommends  a  three  stage  "curriculum" 
approach  to  training  end  users.  In  the  first  stage,  the  "How 
to"  aspects  are  addressed  to  novice  users,  focussing  on  the 
mechanics  of  utilizing  the  hardware  and  an  introduction  to  the 
software.  The  recurrent  training  philosphy  is  embodied  in 
stages  two  and  three.  Stage  two  entails  the  idea  of  educat ing 
users  (and  managers)  instead  of  training,  with  the  focus  on 
concept  development  versus  skill  training.  Stage  three,  which 
may  be  beyond  the  scope  of  SNAP- II,  deals  with  concerns  about 
data  integrity,  documentation  of  software  developed  by  users, 
and  system  accountability,  security  and  controls.  Implementation 
or  stage  one  training,  is  not  completely  ignored  after  imple¬ 
mentation,  as  there  will  always  be  new  users. 

Applied  to  SNAP- 1  I ,  initial  training  has  been 
provided  for,  but  recurrent  training  has  not.  This  type  of 
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training  can  be  divided  into  two  areas--that  which  should  be 
conducted  on  board,  and  that  which  should  be  conducted  at 
fleet  training  centers  or  schools  enroute  to  sea  duty. 


Training  syllabi  and  materials  for  afloat 
recurrent  training  should  be  developed  and  provided  to  ships 
when  the  system  is  implemented.  In  a  paper  on  user  interface 
design  [Ref.  27:p.  171],  Thimbleby  recommends  that  such 
material  be  provided  by  the  designer  of  the  system,  which  in 
this  case  can  be  construed  as  being  either  the  functional 
manager  or  NAVMASSO.  Currently,  the  subject  of  recurrent 
training  is  handled  in  diverse  ways.  Some  ships  have  a  strong 
training  program,  but  it  is  a  re-run  of  the  implementation 
training.  Guidance  is  necessary  so  that  ships  can  carry  on  a 
strong  continuing,  or  recurrent  training  program  to  develop  a 
system-wide  perspective  of  SNAP- 1 1  versus  a  narrow  and  specific 
subsystem  application  view. 

Training  conducted  by  shore  commands  will  not 
be  addressed  here  as  there  is  insufficient  experience  and  data 
to  make  any  objective  evaluations. 

(3)  The  "Selling  of  the  Product".  The  lack  of  a 
systems  perspective  by  the  end-user  managers  may  he  a 
detracting  factor  in  the  successful  implementation  and  use  of 
a  computer  system.  The  manager  must  understand  how  the  system 


affects  him  and  his  personnel.  This  form  of  training,  or 
education,  is  not  present  in  the  training  strategy  of  SNAP-II. 
Eibes  [Ref.  2 7 : p .  22],  in  addition  to  the  various  attributes 


of  stage  two  of  his  three-stage  curriculum,  states  that  the 
"marketing"  or  "selling"  of  an  information  system  to  managers 
occurs  at  this  point: 

However,  a  majority  of  those  receiving  systems  education 
will  originate  from  the  supervisory,  managerial  or  even 
executive  positions  .  .  .  The  process  may  not  even  be 
called  'education',  with  terms  such  as  'marketing'  or 
'selling'  being  preferred. 


V 


CONCLUSIONS  AND  RECOMMENDATIONS 


Given  the  diversity  and  magnitude  of  the  SNAP- II  program, 
a  considerable  degree  of  success  has  been  achieved  in 
implementing  an  interactive  computer  system  in  independent 
afloat  units  having  novice  users,  operators  and  maintainers. 

The  system  has  been  received  in  a  positive  manner  by  all  ships 
that  were  a  part  of  this  review.  A  adjectival  summary  of 
various  aspects  of  the  SNAP-II  program  from  the  end  users 
perspective  is  included  as  Table  VII. 

The  end  users  have  been  generally  satisfied  with  the 
implementation  process.  While  there  have  been  problems  with 
constructing  the  initial  data  bases,  these  are  not  seen  as 
major  obstacles.  The  performance  of  NAVMASSO  and  the  NAVSEACEN 
in  their  implementation  and  support  roles  have  been  consistentl 
very  good. 

The  hardware  and  software  elements  of  the  SNAP- II  program 
have  been  well  received  by  the  ships  reviewed.  The  subject 
of  the  adequacy  of  the  numbers  of  terminals  was  raised 
repeatedly,  suggesting  that  this  area  needs  further  consider¬ 
ation.  As  an  adjunct  to  this,  several  ships  have  reported  that 
the  word  processing  function  seriously  slows  down  system 
response  time,  although  this  was  not  quantifiable.  An 
alternative  to  this,  should  it  be  technically  and  economically 
feasible,  would  be  to  install  "intelligent  terminals”  capable 
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of  handling  the  word  processing  function  locally  instead  of 
in  the  Central  Processing  Unit.  These  terminals  should  remain 
networked  to  the  minicomputer  for  the  purposes  of  performing 
the  designed  SNAP- 1 1  functions. 

The  degree  of  integration  of  the  SNAP- 1 1  system  into  the 
shipboard  operating  environment  has  varied  from  ship  to  ship. 

As  has  been  noted,  some  ships  are  operating  different  types 
of  computer  systems -- some  at  the  basic  transaction  processing 
level,  some  at  a  higher  level.  The  level  of  computer  expertise 
and  character  of  the  command  prior  to  SNAP- II  implementation 
has  had  a  certain  bearing  on  this,  but  there  are  also  external 
intangible,  or  non-material  factors  that  are  influencing  this. 

As  noted,  documentation  for  end  users  was  not  considered 
effective  by  the  ships  interviewed.  Closely  related  to  this 
was  the  type  of  training  being  conducted  for  shipboard 
personnel.  Both  these  areas  require  revision  to  increase  the 
effectiveness  of  the  SNAP-II  system  and  insure  that  all  levels 
of  end  users  are  utilizing  the  system  to  its  full  extent. 

A  difficult  area  to  assess  is  the  SNAP-II  program  itself. 

End  users  have  voiced  concern  about  what  they  perceive  as  a 
lack  of  policy  guidance  and  an  understanding  of  just  how 
SNAP-II  is  to  be  used  in  relation  to  managing  their  ships.  In 
and  of  itself,  this  may  reflect  a  lack  of  adequate  communication 
between  the  fleet  and  program  management. 

The  program  has  provided  for  four  of  the  five  components 
of  a  computer  system  as  defined  by  Kroenke,  leaving  the  key 


area  of  "procedures"  in  an  undefined  state.  This  is  not  a 
fault  of  the  program.  An  analogy  that  best  illustrates  this 
drawback  would  be  the  procurement  of  a  weapon  system.  A 
program  manager  would  be  responsible  for  obtaining  the  hardware 
itself,  but  would  not  be  responsible  for  developing  tactics  to 
employ  it.  This  is  where  SNAP-II  finds  itself. 

Because  of  the  different  functional  managers  and  sponsors 
present  in  the  SNAP-II  program,  there  are  diverse  forces  at 
work.  Each  is  interested  in  ensuring  that  their  subsystems 
are  functional  and  implemented.  While  the  SNAP-II  program 
office  is  concerned  primarily  with  implementing  the  system 
in  the  fleet  (which  it  is  doing  well),  it  appears  no  one  office 
is  charged  with  absolute  control  as  to  what  exactly  the  SNAP- 
II  system  is  to  be  or  how  it  is  to  be  integrated  into  the 
management  of  a  ship.  Ostensibly,  the  Program  Coordinator 
(OP-945)  should  be  in  full  charge  of  these  matters,  but  that 
may  be  impracticable  given  the  nature  of  the  organization- - 
they  are  concerned  with  computer  systems,  not  management  of  a 
ship.  The  identification  of  a  central  point  charged  with 
defining  exactly  what  SNAP-II  is  to  do  and  how  it  is  to  do  it 
is  highly  recommended.  Once  this  is  accomplished,  standards 
can  be  developed  and  promulgated  to  fleet  units. 

Having  implemented  the  SNAP-II  system,  some  gauge  of  its 


effectiveness  and  use  by  fleet  users  is  necessary,  both  to 
point  out  areas  for  possible  improvemer t  in  the  program  and 
to  ascertain  that  fleet  units  are  using  the  system  to  its 


full  benefit.  A  post  implementation  review  process  as  an 
integral  part  of  the  SNAP-II  implementation  process  is  highly 
recommended.  Standards  must  be  developed  to  accomplish  this, 
as  noted  in  the  preceding  paragraphs. 

In  summary,  the  Navy  has  introduced  a  computer  system  that 
has  been  well  received  by  the  fleet  users  interviewed.  However 
there  are  concerns  and  minor  problems  that  prevent  it  from 
being  utilized  to  the  most  efficient  extent  possible.  These 
can  be  corrected  by: 

.  better  communication  with  the  end  user 
.  revision  of  training  policy 
.  revision  of  documentation 

.  identification  of  a  central  control  point  for  program 
policy,  guidance,  and  standards 


APPENDIX  A:  ACRONYMS 


3-M  -  Material  Maintenance  Management  Program 

ADM  -  Admnistrative  Data  Management  Subsystem 

ADP  -  Automated  Data  Processing 

AE  -  Auxiliary  -  Ammunition  ship 

AFS  -  Auxiliary  -  Refrigerated  Stores  ship 

AIS  -  Automated  Information  System 

AMS  -  Aviation  Maintenance  Subsystem 

AO  -  Auxiliary  -  Oiler 

AOE  -  Auxiliary  -  Ammunition/Oiler 

AOR  -  Auxiliary  -  Oiler/Replenishment 

APL  -  Allowance  Parts  List 

ASW  -  Anti-submarine  Warfare 

BB  -  Battleship 

BOR  -  Budget  OPTAR  Report 

CASREP  -  Casualty  Report 

CDA  -  Central  Design  Activity 

CG  -  Guided  Missile 

CGN  -  Guided  Missile  Cruiser  Nuclear  Powered 
CIC  -  Combat  Information  Center 
CK  -  Configuration  Change 

CMPM  -  Current  (Ship's)  Maintenance  Project  Master 
CNO  -  Chief  of  Naval  Operations 
CO  -  Commanding  Officer 


COBOL  -  Common  Business  Oriented  Language 
COM  -  Communications 


COMNAVSURFLANT  -  Commander,  Naval  Surface  Forces,  U.S. 

Atlantic  Fleet 

COMNAVSURFPAC  -  Commander,  Naval  Surface  Forces,  U.S. 

Pacific  Fleet 

COMSUBPAC  -  Commander  Submarine  Force,  U.S.  Pacific  Fleet 

CONUS  -  Continental  United  States 

COSAL  -  Consolidated  Shipboard  Allowance  List 

CPU  -  Central  Processing  Unit 

CSO  -  Combat  Systems  Officer 

CSMP  -  Current  Ship's  Maintenance  Project 

DD  -  Destroyer 

DDG  -  Guided  Missile  Destroyer 
DH  -  Department  Head 
D-LR  -  Depot  Level  Repairable 
DS  -  Data  System  Technician 

DSC  -  Data  System  Technician  Chief  Petty  Officer 
DSS  -  Decision  Support  System 
EM  -  Electrician  Mate 

EMC  -  Electrician  Mate  Chief  Petty  Officer 

EMO  -  Electronics  Material  Officer 

ET  -  Electronics  Technician 

EW  -  Electronic  Warfare  Specialist 

FAS  -  Functional  Area  Supervisor 

FF  -  Frigate 

FFG  -  Guided  Missile  Frigate 


FTC  -  Fleet  Training  Center 
FY  -  Fiscal  Year 


INSURV  -  Board  of  Inspection  and  Survey 

LOGMARS  -  Logistics  Application  of  Automated  Marking  and 
Reading  Symbols 

LPD  -  Landing  Platform  Dock 

LST  -  Landing  Ship  Tank 

MDS  -  Maintenance  Data  Subsystem 

MEASURE  -  Metrology  Automated  System  for  Uniform  Recall  and 
Reporting 

MIS  -  Management  Information  System 

MLS  -  Mobile  Logistics  Support  Force  Subsystem 

MMCM  -  Machinist  Mate  Master  Chief  Petty  Officer 

NAMMSO  -  Navy  Material  Management  Support  Office 

NAVMASSO  -  Navy  Management  Systems  Support  Office 

NAVMASSO  DETPAC  -  Navy  Management  Systems  Support  Office 

Detachment  Pacific 

NAVSEA  -  Naval  Sea  Systems  Command 

NAVSEACENLANT  -  Naval  Sea  Systems  Command  Center  Atlantic 

NAVSEACENPAC  -  Naval  Sea  Systems  Command  Center  Pacific 

NAVSUP  -  Naval  Supply  Systems  Command 

NEC  -  Navy  Enlisted  Classification 

NMPC  -  Navy  Military  Personnel  Command 

NSCS  -  Navy  Supply  Corps  School 

NWS  -  Naval  Weapons  Station 

OMMS  -  Organizational  Maintenance  Management  Subsystem 
OPNAV  -  Office  of  the  Chief  of  Naval  Operations 
OPS  -  Operations  Officer 
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OPTAR  -  Operating  Target 
PC  -  Postal  Clerk 

PCO  -  Prospective  Commanding  Officer 

PCS  -  Permanent  Change  of  Station 

PMS  -  Planned  Maintenance  System 

PN1  -  Personnelman  First  Class 

PNC  -  Personnelman  Chief  Petty  Officer 

PQS  -  Personnel  Qualification  Standard 

RAV  -  Restricted  Availability 

RFT  -  Ready  For  Training 

SDSA  -  Source  Data  System  Afloat 

SECNAV  -  Secretary  of  the  Navy 

SEF  -  Ship's  Equipment  File 

SEL  -  Selected  Equipment  List 

SFM  -  Supply  and  Financial  Management  Subsystem 

SFOEDL  -  Summary  Filled  Order  and  Expenditure  Difference 
Listing 

SFOMS  -  Ship's  Force  Overhaul  Management  System 
SFWL  -  Ship's  Force  Work  List 
SK  -  Storekeeper 

SKC  -  Storekeeper  Chief  Pettv  Officer 

SKCS  -  Storekeeper  Senior  Chief  Petty  Officer 

SMA  -  Systems  Management  American  Corporation 

SMS  -  Systems  Management  Subsystem 

SNAP  -  Shipboard  Non-tactical  ADP  Program 

SOAP  Team  -  Supply  Overhaul  Assistance  Program  Team 


SPCC  -  Ship's  Parts  Control  Center 
SWO  -  Surface  Warfare  Officer 
SWOS  -  Surface  Warfare  Officer  School 
SWOSCOL  -  Surface  Warfare  Officer  School 
TAD  -  Temporary  Additional  Duty 
TECDOC  -  Technical  Document  Module 
TYCOM  -  Type  Commander 

UADPS  -  Uniform  Automated  Data  Processing 

UNREP  -  Underway  Replenishment 

VOS  -  Vulcan  Operating  System 

WSF  -  Weapons  Systems  File 

XO  -  Excutive  Officer 

YNC  -  Yeoman  Chief  Petty  Officer 


System 
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